Hacker News new | past | comments | ask | show | jobs | submit login

Because the timestamp and offset (i.e., a numeric indication of the time zone, as a difference from UTC) aren't actually enough information to calculate the local time, pedantically.

Why not?

1. Leap seconds. They exist at irregularly spaced intervals based on the Earth's actual rotation, which is a) not perfectly consistent and b) ever so slightly, continuously, on average, slowing down. The offset would only allow you to figure this out, in principle, if you already had the UTC time - which has to be calculated from the timestamp in a complex way that accounts for leap second information retrieved from a database.

2. Time zones change over time. Some parts of the world use daylight savings time and others don't. It's possible in principle for a daylight savings time transition (which occurs on different dates in different parts of the world) to occur between two displays of the date, invalidating the offset.

3. Time zones change over (longer periods of) time. They've historically been created, removed or had their borders changed. Sir Sandford Fleming's system is now 148 years old (and there were others before it), and geopolitics happens.

4. Calendars. Maybe you don't care about, say, the eras of the Japanese calendar (https://en.wikipedia.org/wiki/Japanese_era_name), but some applications will require knowing about it. If you need to deal with history, then the conversion between Gregorian and Julian calendars will also depend on locale, because the Gregorian calendar was adopted at different points in different parts of the world.




Aren’t all of those example problems solved with a versioned database of timezones and calendar algorithms? Any past “universal” date can be converted to a fully defined local, contextual time based on such a resource. But, it doesn’t exist.


In theory it's a solvable problem. In practice most libraries handling date and time aren't living up to that expectation, in particular and core system libraries, because it's just hard and tradeoffs are made.


Such databases do exist, and they're how more heavyweight libraries solve the problem. But there has to be code that applies the algorithms; there has to be a reasonable guarantee that the code will actually be used in the appropriate situations; and dates need to encode the information about which database version to use (otherwise you will run into problems e.g. if you're trying to plan around future dates; "render the date according to the current rules for the current locale" isn't always correct, and "render the date according to the rules for the place and time when and where the object was created / data was stored" isn't either, and "render the date according to the rules for the place and time that it represents" isn't either).

tl;dr: dates are hard because they represent an intersection between adjusting a model to meet physical reality, with l10n/i18n concerns (even if you don't care about language translation). Both of those are hard enough individually already.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: