Quote of the week [LWN.net]

always keep timezone information with your timestamps – otherwise, you’ll never know whether it’s 0830 in elephants…

— Matt Palmer (hat tip to Paul Wise)

to post comments

Quote of the week

Posted Nov 14, 2013 18:37 UTC (Thu) by rriggs (guest, #11598) [Link] (8 responses)

Local time and time zones are a finicky, political mess. Time is complex enough as it is. Why make it harder? Store it in UTC and be done with it.

Quote of the week

Posted Nov 14, 2013 22:38 UTC (Thu) by xtifr (guest, #143) [Link]

Merely using UTC doesn't help unless you A) clearly identify it as UTC (as the article suggests) or B) get everyone in the world to agree--a task that would make mere cat-herding look simple by comparison.

Quote of the week

Posted Nov 20, 2013 13:55 UTC (Wed) by robbe (guest, #16131) [Link] (6 responses)

> Store it in UTC and be done with it.

If you ever need to correlate with external systems, you will have to reproduce wall clock time. That means storing the timezone as well. As others have commented, an offset is best. This saves you from carrying complicated logic to compute the offset based on the timezone and date.

I think Israel has changed daylight savings time logic at least 5 times during the last decade.

Quote of the week

Posted Nov 20, 2013 14:54 UTC (Wed) by jzbiciak (guest, #5246) [Link] (2 responses)

Wall clock time from whose perspective, though? The perspective of the viewer, or the perspective of the person who generated the time stamp?

If I do an `ls` on a Linux or UNIX box, it generally shows me time stamps from my own perspective, regardless of the time zone that was set for the task that created / updated the files.

(I say 'generally', because I don't really remember what rules Linux applies to a FAT volume that has files stored with local-time timestamps.)

I'm not against marking clearly that a timestamp is in UTC. Recording the timezone of the person generating the timestamp only really effectively adds location information, and if it isn't stored as a simple offset to UTC, it also requires me to consult a timezone database to interpret it correctly. If I want to compare two timestamps and determine "newest," plain UTC is the simplest.

We actually had a timezone related date problem at work a few years back. We had a "results" database that we used to collect performance analysis figures, so we could monitor the performance of a design as it progressed. We wanted to detect any performance regressions and track them to a particular release. The early database design just stored when the results were measured. It worked well enough until we brought on some contractors in India to help our Dallas-based team. We started getting "time traveling" data, because the timestamps were stored in local-time.

We ended up switching to UTC. (My response was almost exactly as above: "Why are we storing that in localtime? Store it in UTC and be done with it!") We also put some additional columns in there to grab the exact design release tag and the release tag for the analysis scripts, because that timestamp was just a little too overloaded for what we were using it for. (Growing pains...)

Quote of the week

Posted Nov 21, 2013 16:22 UTC (Thu) by robbe (guest, #16131) [Link] (1 responses)

> Wall clock time from whose perspective, though?

Where the event happened. I had something like an event database in mind. Let's say a sensor reading is out of bounds and you want to store that. My point is that, three years later, when the court case is running, you would want to correlate the DB contents with the paper logbook that a worker keeps (in wall clock time, of course!). You would probably be able to, as said worker will be in a definite location with a definite timezone, but storing the offset alongside UTC would make it easier still. And it's only eight bit (seven if you're a miser)!

File systems are an interesting case. We would have to store the timezone offset of the current process updating a file along the utc mtime. Problem being, the timezone is a userland-only concept...

Quote of the week

Posted Nov 21, 2013 17:24 UTC (Thu) by jzbiciak (guest, #5246) [Link]

Storing the offset for the location of the event makes sense if you need to quickly contextualize back into the context where the reading was made, sure. I still vote for recording UTC + offset as opposed to localtime + offset. If you've ever tried to interpret timestamps in SMTP headers, it can be rather confusing for email crossing multiple timezones.

Quote of the week

Posted Nov 20, 2013 16:48 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

Usually you want your permanent time storage to be in UTC and have it marked as such, it's a fixed point of reference. No special calculation needs to be made to compare and correlate timestamps in UTC, which is the common case, the only time you need to do complicated conversions is if you want to reconstitute the observed local time, which requires offset and daylight savings information for that particular point in space and that particular point in time as the conversion is often changed for political reasons. That's why stored timestamps should be in UTC, always.

Quote of the week

Posted Nov 21, 2013 15:44 UTC (Thu) by arielb1@mail.tau.ac.il (guest, #94131) [Link]

Actually, timestamps should probably be stored as a TAI offset from some epoch (NOTE: not TAI dates, counts of TAI seconds from an epoch) - it is actually the thing we want to track.

Quote of the week

Posted Nov 21, 2013 16:13 UTC (Thu) by robbe (guest, #16131) [Link]

On re-re-read, I was not exceptionally clear: I didn't/won't argue against storing UTC. I purport that, in most cases, you should store TZ offset as well.