Hacker News Reader

Comment by msiebuhr | Hacker News Reader

Yes!

No more jet-lagged minors twice a year, no more train tickets stamped ~200 years in the future (yes, that has happened to me) and no more confusing server logs with odd duplicates.

Also, contact your local EU parliament member and politely explain why this is good...

View on HN

Nit: Why isn't the server running in UTC?

I'm seeing more people recommending this. Is the main reason to avoid the daylight savings time changes twice a year, or am I missing something else obvious?

Disclosure: I don't use UTC, I set the server to local time. I'm very open to learning why I'm wrong and how I can improve.

Edit #2: thanks, responders – makes perfect sense when you put it that way. Today I learned.

For logs you avoid having one day with 23 hours and one day with 25 hours per year. You also avoid trouble when running a cronjob at 2:30am, one day it would run twice, another not at all.

You run servers and dbs in UTC then you translate in your app to local times, this is best practice. Otherwise, problems.

The question was what problems and why would I want to do this. Saying problems happen isn't helpful.

If you have multiple servers in different timezones, or devs in different time zones, etc, this can all lead to confusion.

It’s generally best if all your servers have one identical environment – time in UTC, language in english – globally, everywhere.

It's a sanity thing. You're likely going to hit a spot where you need to compare log entries across systems that may or may not be geographically located in the same place.

Let's say your server is in New York, and you set it to local time, so EST.

You store some customer records, customer can see them back and see the time of their record.

Now you move to Los Angeles with your server. Do you set your server to EST still, and have a server in a timezone that has nothing to do with anything anymore (and the knowledge of why gets lost as time goes by).

Or do you set it as PST ? And now what, do you convert your entire database ? Or do you add special code to "fix" the time is the entry is "earlier than X" ? And how do you then handle displaying the time in the customer's own timezone, when he said +4, did he mean yours (EST) + 4 and then it's not good for PST ? What if you have some servers in New York and some in Los Angeles then ? How do you compare stuff ?

UTC is great because it forces you to work in a mindset of "it doesn't matter where the server, the customer or me are, this is the base time, and for everyone I offset it to their respective timezone".

I store my data in UTC anyway. BUT why not include the timezone in the timestamp? Then in your example you can change the server's timezone with no disruption...

Because it's extra parsing in a pinch? If you're storing it in a database it'll be stored as a 64bit unsigned int (a-la UNIX Epoch) of seconds since 1970 (in UTC) but if it's text-file logs I agree that it should be UTC, this has been standard ops practice for 20~ years.

Some programs in your server will use the server clock and don't have a timezone settings.

> why not include the timezone in the timestamp?

I don't think there is an unambiguous way to represent time zones. Time zones are a creation of law and convention. They change, and have changed, over time.

There is an unambiguous way to represent time zones:

UTC±hh:mm

To be pedantic, that's the unambiguous way to represent the UTC offset, not timezones. Different timezones can have the same offset at some moments, but not at others.

GGP probably meant including the UTC offsets in the timestamps, not timezone names like "Europe/Berlin" or whatever.

Right, but the time zone might not have the same offset in the future, they're not interchangeable.

Events in the past are easy: all you really need is UTC time, but if you store local time and the offset from UTC (and optionally the tzdata timezone name) that works too.

For dates in the future, you need to store local time, the timezone name, and the calculated offset for that time. When the database changes, you need to check if the offset changes, and if so, think hard about what that means. Also, some future events are more appropriately scheduled for local time wherever the person happens to be, which is tricky too.

Yes there is. It's called ISO 8601.

https://en.m.wikipedia.org/wiki/ISO_8601

Totally agree! I've run into this problem quite a bit, and I think storing the timezone or offset along with a UTC timestamp is the solution. In particular, I want to be able to:

1. Know when a globally ordered even happens. Using UTC or local time with offsets satisfies this requirement.

2. Know when an event occurred in local time, for example movie show times (I can't know what time to print on the ticket without getting the theater's time zone when passed in UTC). UTC does not solve this problem, but local time with offsets works.

Example of when I wrote this comment:

  $ date -u +"%Y-%m-%dT%H:%M:%SZ"
  2018-02-08T16:17:48Z
  $ date +%FT%T%z
  2018-02-08T08:17:48-0800

Both formats are ISO8601 compatible.

Finally, many client-side requests for dates should be in local wall time without an offset or UTC. Of course this is application dependent, but I've seen this go wrong a few times.

Please share other ideas/suggestions if you have them.

Because then it's denormalized and it's failing to separate concerns. It's storing both the time something happened and the thing strip of longitude it was nominally deemed to have taken place in.

A timezone is a political boundary, not "a thin strip of longitude" (unfortunately)

Set the server to UTC and leave it up to users to choose their own locale settings. You can set the default locale to the local time zone.

Time zones are for people, not machines. The machine does not have a sleep schedule or business hours.

I thought this was a no-brainer since the very first distributed systems. Run everything, everywhere in GMT and translate to local time if you have to in a cosmetic layer

Local time is very idiosyncratic - the hands of the clock on your wall move forwards, backwards, repeat the same hours, skip hours and dance at the will of your people and politicians.

Needless to say, this may cause issues in computers. The only clocks that stay consistent and dependable are the ones in UTC land.

So the people mirror the clocks of their local government, but computers mirror the UTC clocks.

Leap seconds would have a word with you. The only time that's fixed is GPS time, or so I heard.

Legend has it there's a secret order of monks that have been going "one mississippi, ..." since 1970. They say it's the only way they can be really sure.

But nobody knows how, when or why they came to be 23 minutes off ...

> The only clocks that stay consistent and dependable are the ones in UTC land.

UTC is closer to “consistent and dependable” than local time, but still has leap second issues. TAI is where you go for consistent and dependable.

Re leap seconds, smearing seems to have solved that rather effectively. The last leap second was a non event thanks to it.

If people do leap second smearing anyway, I wonder if it were possible to just directly use UT1 instead of UTC (the leapseconds are just there to keep UTC synchronized to UT1 to within one second).

It's not just DST. Timezones change, like leap seconds, in a way that's not computer friendly.

Probably because it's an old system the OP has to deal with but cannot re-engineer from the ground up. At least, that's usually my experience.

Some people just don't have a global mindset, I guess.

Why is everyone talking about storing data in a presentation format rather than an unambiguous format? Just because it's a log doesn't mean it's not a type of data that should be stored appropriately.

Because integer (milli/nano)seconds since epoch isn't a human-readable format, and logs need to be read by humans, particularly under stressful conditions.

Furthermore, won't Unix time, the most common format, blow up in 2038?

It will overflow a 32 bit integer around that time. If you are using a 64 bit representation, then you'll be fine.

32 bit signed integer. Unsigned will be fine for a good while yet.

Picked: Because UTC is hardly 'U', and imposes a rampant heliocentricitism. If anything, it can purport to be at most GTC, which would be good enough for a while longer I suppose.

> Also, contact your local EU parliament member and politely explain why this is good...

The constituency I last voted in has 3 MEPs for a population of 900,000... I'd be amazed to ever see them, let alone hear back from them.

I doubt that many write to MEPs.

Reply on news.ycombinator.com