Why You Should Use Timezone Offsets Not Timezone Names • Hacker News Board

Re: Why You Should Use Timezone Offsets Not Timezone Names

#11

Post by gioele » Mon, Aug 10, 2015, 6:18 AM UTC

In my past studies of documents-as-they-were-in-another-point-in-time I understood that the best way to deal with time-related information is to store all the context that you have. In this case

* store the appointment date and place as a string "february 23 at 6pm here"; * store the time when the date has been uttered/written in UTC or, better, TAI; * store the place where the date has been uttered/written: "Europe/Rome" or, better, GPS coordinates.

These three pieces allows you to convert the target date to any timezone, even in case the definition of timezones changes.

This three-pieces encoding is very helpful during legal disputes as it allows you to say "On a certain date we agreed on this date in the future. At the time the appointment was supposed to be XXX hours away. The fact that is now only YYY hours away is not our fault but the consequence of country CCC changing to a different time zone." It also works well for other imprecise utterances like "tomorrow".

Re: Why You Should Use Timezone Offsets Not Timezone Names

#12

Post by lambda » Mon, Aug 10, 2015, 6:26 AM UTC

jchavannes wrote: post #9

lambda wrote: post #8

Earlier quoted context omitted.

Unix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).

leap seconds, or the like What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2]. Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain. [1] https://dev.m…

The "or the like" was the end of the list of ways in which you could model the divergence between Unix time and the number of SI seconds between January 1st 1970 UTC and the present.

One way of modelling it is as saying that seconds in Unix time all have the same length, that differs by some factor from SI seconds, though that factor changes every time a leap second is introduced.

Another way is to say that seconds don't all have constant length; some seconds have a different length than the rest of the seconds (like those in the hour or day leading up to a leap second, or even just that the one second before the leap second is twice as long as a regular second).

The "or the like" was just a hedge against other possible ways of describing this divergence that I hadn't described in that one quick sentence.

Pretending that leap seconds don't exist is all well and good if you have a completely closed system, but as soon as you try to synchronize with or compare timestamps with UTC, you'll start running into problems.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#13

Post by mikehotel » Mon, Aug 10, 2015, 6:34 AM UTC

jchavannes wrote: post #9

lambda wrote: post #8

Earlier quoted context omitted.

Unix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).

leap seconds, or the like What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2]. Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain. [1] https://dev.m…

How is Google's leap smear idea pretending like leap seconds don't exist? As per your link, "The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens."

Re: Why You Should Use Timezone Offsets Not Timezone Names

#14

Post by [deleted] » Mon, Aug 10, 2015, 6:41 AM UTC

mikehotel wrote: post #13

jchavannes wrote: post #9

Earlier quoted context omitted.

leap seconds, or the like What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2]. Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain. [1] https://dev.m…

How is Google's leap smear idea pretending like leap seconds don't exist? As per your link, "The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens."

[deleted]

Re: Why You Should Use Timezone Offsets Not Timezone Names

#15

Post by Zarel » Mon, Aug 10, 2015, 6:44 AM UTC

wizardry90210 wrote: post #4

The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any fut…

I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database.

The ones that have a tiny map that you have to click on are also pretty bad.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#16

Post by jchavannes » Mon, Aug 10, 2015, 6:45 AM UTC

mikehotel wrote: post #13

jchavannes wrote: post #9

Earlier quoted context omitted.

leap seconds, or the like What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2]. Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain. [1] https://dev.m…

How is Google's leap smear idea pretending like leap seconds don't exist? As per your link, "The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens."

From the article:

> Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. [..] Rather than doing this, we applied a patch to our internal NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight

Re: Why You Should Use Timezone Offsets Not Timezone Names

#17

Post by tadfisher » Mon, Aug 10, 2015, 6:46 AM UTC

lambda wrote: post #6

wizardry90210 wrote: post #4

The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any fut…

I think the main thing to remember is that dates and times have very different semantics when used for different purposes. If you are referring to an instant in time, then just using UTC is reasonable. If you are referring to a past event and both the local time and precise instant are relevant, then the local time with a timezone offset is reasonable. If you are scheduling events on a calendar, however, like "8 AM e…

TZDATA ships with historical timezone information, so using the timezone name should also work for past events, no?

Re: Why You Should Use Timezone Offsets Not Timezone Names

#18

Post by saurik » Mon, Aug 10, 2015, 6:48 AM UTC

Zarel wrote: post #15

wizardry90210 wrote: post #4

The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any fut…

I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.

CST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#19

Post by Zarel » Mon, Aug 10, 2015, 6:50 AM UTC

saurik wrote: post #18

Zarel wrote: post #15

Earlier quoted context omitted.

I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.

CST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.

My bad, I'll update my comment.

Re: Why You Should Use Timezone Offsets Not Timezone Names

#20

Post by erpellan » Mon, Aug 10, 2015, 6:51 AM UTC

Unqualified absolute statements (like this one!) are always wrong.

It's not possible to make a generalized assertion about the correct way to deal with time. If you're building a global distributed database, you probably want all your timestamps in UTC. If you're building a calendar application, not so much.

Some systems also need to record the time the observation was made, introducing a 2nd dimension of time. This becomes important very quickly when trying to design a system with an immutable (append-only) data store.