Skip to content

Comment on Microsoft confirms Exchange Year 2022 problemparent

Comments

Calendar appointments are a good example where a timestamp without a timezone (java's Instant) is appropriate. But a birthday doesn't have a time, so you would want to use LocalDate (a date without a time and timezone) for that.

In 99% of the cases you only really want to involve timezones when presenting something to the user or taking input from them.

So you would create your calendar event by entering "9am, timezone X", and the app would most probably just apply that offset and store that as a timestamp. But if it's an all-day event... I should probably take a look at android's calendar content provider.

Not storing absolute times is a disaster. If it's seemingly working now it's only because your use case apparently doesn't include anything cross-timezone.

Referring to something like "Christmas day" as timezoneless doesn't help either. Anyone who celebrates it celebrates it in a timezone. Christmas Day EST is a different event than Christmas Day CEST. Trying to represent them as the same event will only lead to heartbreak.

Birthdays are an exception to this rule.

Generally I think Dates (without time) are usually considered time-less and therefore timezone-less.

In fact the examples you mention are only a concern when considering the start or end of Christmas Day, and not the actual date of Christmas Day.

The problem I see is that at some point you will try to decide whether it's currently Christmas or not. That's when things start falling apart.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.