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.
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.
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.
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.