Hacker News Reader

Comment by worik | Hacker News Reader

> strange gaps in logs and code didn't have to deal with time changes.

Use UTC for everything, except when displaying then convert at the last moment in UI code

The U in UTC is for Universal.

Except if you don't include time zone info with your timestamps, even with UTC, some system will inevitably interpret it as local time.

You apply your local timezone to the UTC value. There is no reason to store a timezone with it.

The weird thing is you need to always apply the timezone when reading, and un-apply it when writing. This needs to happen at the lowest level of access.

I know how you can convert UTC to local time. The problem is that without timezone info, some system can parse the UTC time AS local time. There is no reason for most date parsing libraries to assume that they are always being fed UTC times and from what I've seen, most date parsing libraries assume timestamps without timezones are in local time unless told otherwise. You can avoid all of this by always storing and passing around timestamps with timezones.

Which is why your system’s time zone should also bet set to UTC.

Don't use that for future appointment times though. When someone books a 9am appointment in 6 months they want that at 9am of whatever timezone it will be at that time and location.

Don't use it for past times either without thinking what you'll use it for. If you want to generate reports of historical data in the user's timezone at the time of the event, you can't convert back just knowing their current timezone. [0]

[0] https://blog.nytsoi.net/2022/03/13/utc

I don’t like UTC because I don’t like doing -8 in my head. In Arizona time I can read raw logs easily.

I've been reading UTC times from all over the world for 20 years ... I've never had any issues. You only have to convert once: the time of the incident.

When you work on a consumer app, it's often important to correlate incident events to real clock time, especially if an external event caused the incident. It's much easier when your logs match your clock.

Speaking from my 30 years of experience reading logs. :)

It depends on where in the world you are as to what "real clock time" means. UTC is an actual timezone ;)

Easy solution. Just don't read logs.

Speaking from my 26 years of experience never reading logs.

I am a strong believer in not storing logs, as they tend not to be useful after a few minutes, other than security logs. But I do find real time logs to be useful information for incident response.

> especially if an external event caused the incident

this has a trivial solution - you convert the times of external events to UTC as well.

for example, the Super Bowl is going to cause a spike in traffic. the Super Bowl this year had its kickoff at 23:30 UTC.

> It's much easier when your logs match your clock.

part of the point of UTC is that "your clock" shouldn't be viewed as privileged or universal. because other people have different clocks.

what you're doing with this Arizona trick is basically inventing "UTC, but slightly different and more convenient for me specifically"

you get used to doing this "they usually match, except 4 months of the year they're off-by-one" trick. but then you're on a business trip to New York, and now you have to remember that it's either a 2 or 3 hour difference, depending on the time of year.

or, you hire a remote engineer in Adelaide, which is UTC+9:30 or UTC+10:30 depending on DST. do you want that engineer to be doing half-hour addition & subtraction in their head in order to correlate log timestamps in Arizona time with their local clock? also keep in mind they're in the southern hemisphere, so they have "summer time" reversed from the northern hemisphere, and they do 6 months on and 6 months off instead of 8 and 4 as the US does [0].

every desktop environment I know of supports adding a second clock with a different timezone to the system tray. on my work machines I have one for my local time, and one for UTC. it's very easy to look at the latter when I want to know "what's the current time as far as my servers are concerned".

[0] https://www.timeanddate.com/time/zone/australia/adelaide

I find UTC painful from a West Coast perspective, too. -8 is 1/3 of a day, and it puts the UTC date rollover at either 4pm or 5pm depending on DST. It genuinely makes solving problems using logs twice as difficult, as a lot of problems strangely tend to happen around that time.

Reply on news.ycombinator.com