Hacker News Reader

Comment by chrisdbanks | Hacker News Reader

One issue with having your servers not in UTC will be that you're always wondering whether other software e.g. logging software is using UTC or local time. Also, in your database you should always use UTC if you have daylight saving time or else you might have surprising issues where records are out of order by date during time changes. Also, what happens when you start a collaboration with a university in another country and suddenly have users in another time zone. As someone who's worked on many projects with timezones I've seen many people make arguments for not using UTC. Something always comes along that makes them wish they'd used UTC. If you use UTC for everything then you're always sure it's UTC, and it's easy to make the conversion. Otherwise you're always unsure and the costs of uncertainty can be very high indeed.

View on HN

Unix does the sensible thing and records timestamps in seconds since the epoch. The epoch is always 1970 January 1 00:00:00 UTC. Timestamps in logs and sent over the wire in that format then don't have a timezone encoded because the "timezone" only gets applied when converting to a format that encodes time of day. When used as a wire format this also allows every device to display the time in its own timezone.

> Unix does the sensible thing and records timestamps in seconds since the epoch.

If only, but unfortunately that's not how UNIX time works. Instead its more like number of days since epoch * 86400 + seconds since midnight. Which is 27 seconds different than simple seconds since epoch count. This is why I would advise against using UNIX timestamps for anything critical because they are fundamentally ambiguous

> Instead its more like number of days since epoch * 86400 + seconds since midnight. Which is 27 seconds different than simple seconds since epoch count.

Yeah, the people who decided to do that were Wrong.

Fortunately it only really matters during leap seconds, and nothing stops you from doing it the right way and having your timestamps in actual seconds since epoch and then converting to "Unix time" or anything else you need. See e.g. libtai:

https://cr.yp.to/libtai.html

In your database, you should always use types with time zones.

Or Unix time.

Not sure about all different databases but Postgres, for example, always stores datetimes in UTC and converts them back to a display timezone when outputting the values[0].

> For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone.

[0] https://www.postgresql.org/docs/current/datatype-datetime.ht...

You're assuming that the "timestamp with time zone" type is always used. I've worked on an application where it was assumed/required that UTC was configured on the server level, so regular timestamps were used. Didn't agree with that at all, but it happens.

Time stamp + TZ is a useful feature if you want to store TZ along with the time stamp. But I think that’s nearly always a bad approach. The only part of your system that needs the time stamp converted into a TZ is your human user. Performing that conversion on the presentation layer will almost always lead to less complexity.

The most common situation I know of where you store the time with its original TZ is when dealing with recurring times (opening/closing items, appointments), as you need to follow the original DST/summertime the user was in.

Which also requires you to store the TZ location (ie city) and not just the name or offset of the timezone itself.

Yeah, I meant to put a “usually” qualifier in that previous comment. Rostering has the same problem. Event scheduling can also run into similar problems. The best solution really depends on a lot of context specific details, but most of the better solutions I’ve personally seen have put TZ in a seperate field, rather than using TZ-typed timestamps, and then use the TZ when required instead of as the default storage format.

For recording when something happend, that makes some sense. Though if you want to report the day of an event, it is still neccesary to include a timezone.

For planned events, it becomes really hard to determine what to do when changing locale.

Reply on news.ycombinator.com