3 ms·

Great article. The author suggests saving time in two formats, (1) UTC and (2) local date-time with a geographical time zone. The app would then pick the right

by gcv 17y ago

Great article. The author suggests saving time in two formats, (1) UTC and (2) local date-time with a geographical time zone. The app would then pick the right one to use depending on context. BTW, let me take the opportunity to praise the Joda Time library for JVM languages. First time I've ever seen date and time primitives implemented well. It can be used for the scheme suggested in the article.

jbert 17y ago
> (2) local date-time with a geographical time zone. Note that timezones aren't just geographical. In London, you'll be in timezone GMT (+0000) for half the year and timezone BST (+0100) for half the year. If you think instead that you're in a single timezone, then you need to know that your "timezone" isn't linear, it contained 00:00->01:00 twice on 25th October 2009 this year (when the clocks go back). So "what was the UTC time for 00:30 on 25th October 2009 in London" isn't a question with a well-defined (or unique) answer.
- gcv 17y ago
  Thanks, I didn't know that! With regard to the non-geographical "timezone" concept, is that what the time zone ID string concept "Europe/London" aims to solve (along with historical and assumed future rules specifying time changes)? I always wondered why those were used.
- arohner 17y ago
  > Note that timezones aren't just geographical. In London, you'll be in timezone GMT (+0000) for half the year and timezone BST (+0100) for half the year. You're comparing apples and oranges. There are two different concepts here: 1) the name of a UTC offset for a given period of time in a given region i.e. BST. 2) the geographic area that has a set of rules about when to change the UTC offset. In the US, we call #1 "Central Standard Time or Central Daylight Time" and #2 "Central Time". #1 means "UTC -6", and #2 means "convert UTC according to whatever the current rule is". The author's point is to store local time + concept #2. EDIT: ok, I see what you mean. If the user types in "send me a reminder at 12:30 Oct 25 London time, you don't know whether they're talking about pre-DST, or post-DST. Interesting.

by gcv 17y ago

jbert 17y ago

> (2) local date-time with a geographical time zone. Note that timezones aren't just geographical. In London, you'll be in timezone GMT (+0000) for half the year and timezone BST (+0100) for half the year. If you think instead that you're in a single timezone, then you need to know that your "timezone" isn't linear, it contained 00:00->01:00 twice on 25th October 2009 this year (when the clocks go back). So "what was the UTC time for 00:30 on 25th October 2009 in London" isn't a question with a well-defined (or unique) answer.

gcv 17y ago
Thanks, I didn't know that! With regard to the non-geographical "timezone" concept, is that what the time zone ID string concept "Europe/London" aims to solve (along with historical and assumed future rules specifying time changes)? I always wondered why those were used.
arohner 17y ago
> Note that timezones aren't just geographical. In London, you'll be in timezone GMT (+0000) for half the year and timezone BST (+0100) for half the year. You're comparing apples and oranges. There are two different concepts here: 1) the name of a UTC offset for a given period of time in a given region i.e. BST. 2) the geographic area that has a set of rules about when to change the UTC offset. In the US, we call #1 "Central Standard Time or Central Daylight Time" and #2 "Central Time". #1 means "UTC -6", and #2 means "convert UTC according to whatever the current rule is". The author's point is to store local time + concept #2. EDIT: ok, I see what you mean. If the user types in "send me a reminder at 12:30 Oct 25 London time, you don't know whether they're talking about pre-DST, or post-DST. Interesting.