3 ms·
> (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 ye
by 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 agoThanks, 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.