Hi Rick.
Rick Measham wrote:
> Looks good to a point .. however you're duplicating data or missing data
> depending on how you're defining your time zone.
>
> If your time zone is 'Australia/Melbourne' then you're duplicating it.
> 2005-06-10 can only ever be non-daylight savings and so your optional
> 'D' is redundant.
Yes, I'm using these timezone names. You're right in that I'm
duplicating information for all times except for the repeated hour.
> However if your time zone is a UTC offset (such as +1000) then you're
> missing data. See right now Hobart, Melbourne, Sydney and Brisbane are
> all at UTC+1000, so given a datetime such as:
> "2005/06/10T21:47:00/+1000", to use your format, we seem to be OK.
> However the problem is calculating around the DST changeover and once
> DST is in effect. See Hobart changes one weekend, then the next weekend
> Melbourne and Sydney will change, and Brisbane have cleverly decided
> that DST is silly and so will never change. Given your string we can't
> know which of these zones to follow for the change (or even if we might
> be in any of the other possible +1000 zones)
Yeah, I think storing the timezone name is better.
> The best way to serialize is to store the Olson Time Zone with an ISO date:
> '2005-06-10T21:47:00 Australia/Melbourne'
> (If that's too long I'm sure it wouldn't be hard for you to create zone
> abreviations such as AUho AUme AUsy and AYbr which would then be
> reinflated before turning back into DateTime objects.)
But then can't you get an ambiguous time? Is '2005-10-30T01:30:00
Australia/Melbourne' the first or the second 1:30am on October 30?
Since I can construct a DateTime for a time in an arbitrary timezone, I
feel like I should be able to construct it unambiguously.
Thanks,
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
