> > Speaking as an end user! I think that a module should either a) do > > what the user expects or b) die because it's not possible to do > > exactly what the user asked for. As I said I don't think turning > > -0600 into UTC is reasonably what the user asked for. > > Depends. Did they want output with offset, or did they want to represent > a particular time and date? If the former, they chose the wrong format. > If the latter, a conversion to UTC should be good.
Well at least we both agree that the current behavior is broken. :) > So, how do I represent Adelaide's date+time. Assume I've been given > +09:30 as my offset. How does this translate to military A-Z? There is no direct correspondence in that system. It would fall under 'I' (+9:00). > [I'd check the other url you sent me but forgot to look at it at home; > currently at work with no graphical browser] http://aa.usno.navy.mil/faq/docs/world_tzones.html [big snip] > Or should the module just croak? I think so. > Basically, the question is, I think: > + If we can represent a date/time in a particular format, > but with having to lose some sort of information (e.g. > explicit timezone or offset or attoseconds), should we? UHH, err, umm... ??? Thats a much larger scope then I was trying to address. Still a very valid question. I hope Dave has some thoughts on this? [I think] The question at hand is how (or if we can) convert from an offset to timezone. If so: how? I ordered a copy of "Calendrical Calculations: The Millennium Edition" yesterday. Maybe if I can find time to read a few chapters I'll come up with a more authoritative answer. Cheers, -J --
