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

I ran into a big problem with timezones when I was in the Navy.

I was in charge of a big supply database server on an aircraft carrier, and every time we changed timezones I had to update the timezone on the server. Heading from East to West was no problem, but when we went from West to East I had to shut the server down for an hour when changing timezones, to prevent timestamps from overlapping.

Admittedly, this was partially due to bad programming, but it's just a small real-world example of problems caused by the existence of timezones.




It's wholly due to bad programming. Put the timestamps in epoch time - that never changes, then read them back in whatever your current timezone is. If you're in a situation like you were where timezones change frequently, you'll also need to record the timezone when the entry was made for reference.

Given that servers frequently changing timezones can be sorted out by a modicum of thought by programmers and is actually pretty rare in the grand scheme of things, I don't think it's too heavy a price to pay.


Best practice - whatever time zone the people are using, keep the internal time stamps on a single time zone (usually UTC). Then just convert the times from and to the local zone for input and display, respectively.


> keep the internal time stamps on a single time zone (usually UTC)

Or UNIX time. While not monotonically increasing (it has issues with UTC leap seconds), it's pretty good.


Just store all the dates and times in UTC, then convert to local time




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: