[Zope3-dev] Re: [Python-Dev] Holes in time

[Aahz]

On Thu, Jan 02, 2003, Tim Peters wrote:
> [Aahz]
>>
>> It sure sounds like you're saying that the DateTime module can't handle
>> timezone conversions at all.
> 
> Nope, overall it does very well.  Go back to the original msg: there
> are glitches during two hours per year, for tzinfo classes that try to
> model both daylight and standard time.  That's it.
>
>> If it can, I don't understand what extra ambiguity (in human terms)
>> is introduced by DST, as long as there are no round-trip conversions.
> 
> Sorry, I can't explain this any better than it's already been
> explained.  There's no ambiguity in EST or EDT on their own, there is
> ambiguity twice a year in a single class that tries to combine both.

So there's ambiguity.  So what?  What I don't understand is why it's a
problem.  More precisely, I see these problems existing in the absence of
computers, and I don't see where creating a Python DateTime class creates
any more problems or makes the existing problems worse -- as long as you
don't try to convert between timezones in the absence of sufficient
information.

>> If not, then the chart from your message starting this thread doesn't
>> apply, because here you're talking about converting from wall clock to
>> wall clock, which I think is a conversion that makes no sense
> 
> Of course it does: at any moment, you can call Guido, and if he
> answers the phone <wink> you can ask him what his wall clock says.  He
> doesn't have to convert his local time to UTC to answer the question,
> and neither do you.  There's "almost never" a problem with this,
> either.

But that's not a conversion.

>> If Guido's appointment does get converted to UTC, then there's always a
>> sensible (if possibly ambiguous) conversion to wall time, and if he
>> looks at his calendar, he should be able to see if his appointment got
>> converted to UTC correctly.
> 
> Fine, pretend Guido lives in Greenwich and UTC is his local time.  The
> ambiguity remains, and it doesn't matter whether Guido can detect it:
> by hypothesis, *you're* the one looking at his calendar, and in your
> local time.  If an appointment then shows up as starting at 1:00 in
> your local time on the day daylight time ends for you, you're most
> likely to believe that's your daylight time (assuming you live in
> the US and in an area that observes DST).  It may or may not be in
> reality, and whether that matters depends on the use you make of the
> information.

>From my POV, this problem exists regardless of whether a computer
mediates the transaction.  The most likely error (if one happens) is that
someone shows up an hour early for the appointment, and presumably that
person knows that the day is a DST transition.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"There are three kinds of lies: Lies, Damn Lies, and Statistics."  --Disraeli