I don't want to drag discussion on too much longer, and moving way off the original topic, but I do have an implementation question.
On Fri, Mar 8, 2013 at 11:48 PM, Jim Monty <jim.mo...@yahoo.com> wrote: > Bill Moseley wrote: > > UTC is a timezone, too. > Yes, poor choice of words. That sentence I wrote doesn't make much sense. I think I was saying to represent a *point in time* you need a timezone, where a timezone is an offset from UTC (including +00:00 offset). I was thinking about Postgresql at that time. But, that's still wrong for the word timezone. I'm not sure how Postgresql internally represents its "timestamp with time zone", but it looks more like it's a "timestamp with offset". 2012-09-07 15:26:40.338969-07 Offset is from UTC, of course, so that's always a point in time, correct? I think this is the point Karen was emphasizing: don't record times > in a computer database in local time (in time zones) because these > expressions of time are rule-based and have too many anomalies in them, > which UTC representations of time do not have: a missing hour in some > days, a repeated hour in other days, etc. > Again, I agree with Karen. There's no perfect answer, right? We (humans) mostly work with local times. Say, I set my alarm for 9am local time on March 8th 2015 (when DST is scheduled to begin) and then convert that to UTC and store. Then if DST is abolished between now and then my alarm will go off at the "wrong" local time. So, here's the implementation question. In a web app a user might enter a time, say 9:00am in the future, when some event should happen. We know their timezone is America/New_York. So, we create a DateTime object DateTime->new ( hour => 9, time_zone => 'America/New_York', ... ); Then we use DateTime::Format::Pg to format that to store in a "timestamp with time zone" column. Am I correct that DateTime (or the formatter) does its best to determine the * offset* from UTC at that time in the future and stores that? Would you implement that differently? But, between now and that future time politics could change DST resulting in the event not really happening at 9am in New York on that day, correct? That's a risk. There's too many ambiguities. Does the user really mean 9am in New York? Or 9am in whatever their current time zone is on that day? Maybe in this case should really store with a local time zone "9am America/New_York". Probably best to not schedule anything too far into the future... -- Bill Moseley mose...@hank.org
