> When storing localtime+timezone, do as the article recommends. Store the timezone, not the offset from UTC. Store "New York time" not EST or EDT. The problem

> When storing localtime+timezone, do as the article recommends. Store the timezone, not the offset from UTC. Store "New York time" not EST or EDT. The problem is that that isn't well defined, as I point out here: http://news.ycombinator.com/item?id=919407 http://news.ycombinator.com/item?id=919407 There are two UTC times corresponding to each moment from 00:00->01:00 25th Oct 2009 "London Time". There are no UTC times corresponding to 01:00->02:00 29th March 2009 "London Time". > Also there is the possibility that you actually want to store the timezone information at write-time, rather than assuming a timezone at read-time. Whether a given time should be displayed in the viewer's localtime or another time is a display issue (I may want to switch between seeing my plane arrival time in localtime of the destination and localtime of my body clock). I don't think it should affect the internal storage format as without help from a strong type system (or some strong coding conventions) coders will intermingle the two types and miss errors in testing either due to geographical proximity or lack of testing over daylight savings boundaries. [All the above saud, the problem of changing DST parameters and future event times is problematic. I think it depends on what you want to be doing with such a time. Note that you'd have the opposite bug if you were storing pre-calculated sunrise time in various locales, so it's an issue of the semantic meaning of the timestamp.]