5 ms·

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

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.

zrm 6y ago
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.
- zokier 6y ago
  > 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
  - zrm 6y ago
    > 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 https://cr.yp.to/libtai.html
aib 6y ago
In your database, you should always use types with time zones.
- eVeechu7 6y ago
  Or Unix time.
- dmlittle 6y ago
  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.html https://www.postgresql.org/docs/current/datatype-datetime.ht...
  - raziel2p 6y ago
    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.
- AmericanChopper 6y ago
  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.
  - unilynx 6y ago
    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.

zrm 6y ago

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.

zokier 6y ago
> 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
- zrm 6y ago
  > 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 https://cr.yp.to/libtai.html

aib 6y ago

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

eVeechu7 6y ago
Or Unix time.
dmlittle 6y ago
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.html https://www.postgresql.org/docs/current/datatype-datetime.ht...
- raziel2p 6y ago
  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.
AmericanChopper 6y ago
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.
- unilynx 6y ago
  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.