3 ms·
> 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 cod
by worik 3y ago
> 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.
- manicennui 3y agoExcept if you don't include time zone info with your timestamps, even with UTC, some system will inevitably interpret it as local time.
- phkahler 3y agoYou 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.
- manicennui 3y agoI 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.
- fmajid 3y agoWhich is why your system’s time zone should also bet set to UTC.
- jedberg 3y agoI don’t like UTC because I don’t like doing -8 in my head. In Arizona time I can read raw logs easily.
- withinboredom 3y agoI'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.
- jedberg 3y agoWhen 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. :)
- joshmanders 3y agoEasy solution. Just don't read logs. Speaking from my 26 years of experience never reading logs.
- jedberg 3y agoI 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.
- withinboredom 3y agoIt depends on where in the world you are as to what "real clock time" means. UTC is an actual timezone ;)
- evil-olive 3y ago> 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 https://www.timeanddate.com/time/zone/australia/adelaide
- wvenable 3y agoDon'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.
- Ndymium 3y agoDon'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 https://blog.nytsoi.net/2022/03/13/utc