Time Zone Problems

Time seems really straightforward and turns out not to be.

Transported image. source Original comic. source

"Daylight savings time is an oxymoron in every programming language ever." tweet

See many different ways to model time (though not timezones) in Eric Evans' Exploring Time

For a geometric model for thinking about time zones, see TickTock.json

//apparatus.wiki.dbbs.co/?load=saves/TickTock.json&fullScreen=1&viewOnly=1&editLink=1&regionOfInterest={"x":[-4,4],"y":[-4,4]} HEIGHT 300 A model of time zones. Exploring Time

Constructing that Apparatus model was its own reminder of how many ways there are to screw up time representations. One must get the order exactly correct when computing local time from UTC and the timezone offset. One must get the integer sign correct when translating time units into radians for the positions of hands on a clock. Getting the relations correct between the position of the sun and the positions of our observer or UTC can also be painfully inverted.

.

Why is 11am + 1 hour 12 pm? stackoverflow

UTC is enough for everyone, right? blog

Universal Dial Plate 1854. Time zones used to be even more difficult. source

> So you’ve got a bunch of scientist types around 1960 who are like, hey, time is all screwy we should totes make a standard. And some of them spoke English, and some of them spoke French, which, of course, is the cause of so much conflict over so many generations. (In hindsight, maybe we should have split all those troublemakers up from the start.) > > The English-speaking folk were like yo, this definitely sounds like Coordinated Universal Time, boom, ship it. And the French speakers were like yeah that makes total sense! Temps Universel Coordonné DOES work out well in our language, too, ship it! Then they both looked up and realized cool, they’ve created both CUT and TUC for acronyms. Shit. > > When your standard — that is expressly meant to standardize time — doesn’t even standardize on a standard acronym, well, damn, that probably doesn’t bode well for your standard. > > Or, actually, now that I think about it, this might be the most perfect metaphor about time itself ever created. Maybe we should give them some credit for that. Time never makes sense. > > Anyway, the compromise that arose was that if everyone is special, no one is special, so they created an entirely new set of letters that has no direct relation to any real words for the compromise: UTC.

These posts reminded me that Jon Udell wrote A Literary Appreciation of the Olson Database (of timezones): blog

A comment in Udell's blog points to Mark Crispin's calendar work for the University of Washington IMAP server: doc

Springs and Neaps: wayback of use Perl;

.

A specific example where my thinking around timezones goes awry.

I live in Boulder which is within the US/Mountain time zone. In summer when we observe daylight savings time, we are in UTC-6.

My head hangs on to the -6.

Looking at a timestamp expressed in Mountain Daylight Time, say 15:00. I remember -6. I speculate that the equivalent time in UTC must be 09:00. Here I've got it backwards. The time I know, x, is 15:00

15:00 MDT

MDT = UTC - 6

MDT + 6 = UTC

15:00 + 6 = 21:00

When converting from Mountain to UTC I need to add. When converting from UTC to Mountain I need to subtract.

As I write this it is all very clear. But when my attention is on some sequence of timestamped events and I'm second-guessing which thing came first because one is expressed in UTC and the other in MDT, my memory fails consistently.

"Do I add six to the UTC or add six to the MDT?" "No wait. Do I subtract 6 from UTC or from the MDT?"

It always feels particularly stupid. Can I not even add or subtract 6?

"Ok. London is east of Boulder. When the sun is straight over head in London, it'll be early morning here. Now which timestamp again?"

I cannot solve these problems in my head. I have to stop and use paper.