Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There’s a difference between a point in physical time, and a coordinate on a calendar. UTC works great for points in time, both past and future. So UTC is very appropriate for logging, including of financial transactions, where often what matters is the exact point in time something happens and not how that maps to someone’s calendar or the time zone on a server.

But UTC doesn’t work at all for a calendar app, where a calendar entry could for example span a calendar day, in some specific time zone, especially if it is in the future and there is not yet a mapping between that future date and UTC.



The mapping to someone’s calendar is important too, though, when you start looking at accruals…


And you need all the mapping rules for the past. Say, we got rid of daylight savings time starting next year. The year after that, what happens when you look at a time/date a decade before?


The IANA (“Olson”) database handles this.


That handles the time "now". Assume within 3 years, a country changed timezones 2 times. If you rely on TZDB, you can never be sure "What happened on May <year> 16.00?". It happened in Turkey and it was a bad time to be a sysadmin.




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

Search: