[Python-Dev] datetime +/- scalars (int, long, float)?

Paul Svensson paul@svensson.org
Tue, 5 Mar 2002 15:21:39 -0500 (EST)


On Tue, 5 Mar 2002, Guido van Rossum wrote:

(---)

>I think I want to introduce a new concept, closely related to local
>time, that I'll dub "naive time" for now.  In naive time, there is no
>timezone and there is no DST.  To compensate for DST, you have to
>manually change the clock, which is an action outside the system,
>unknown to the system, and irrelevant to the working of the system.
>Ditto to change time zones.
>
>Naive time is what you see on your watch or your Palm organizer
>(apparently not on PocketPC or Windows/CE though, which are timezone
>aware).  A day is always 24 hours, and the clock always shows local
>time.  When the DST jump happens, you lose or win an hour but you do
>your best to pretend it didn't happen, by going to bed a little
>earlier or by partying a little longer (or any other activity that
>causes memory loss :-).

(---)

>My Palm has no problem keeping track of appointments in different
>timezones: when I have a meeting in San Francisco at 11am, I enter it
>at 11am, and when I fly there, I move the Palm's clock three hours
>back.  Naive time adapts to local time -- time flies (or stands still)
>when you're in an airplane crossing timezones.
>
>Naive time calculations are easier than local time calculations,
>because they don't have to worry about DST.  You only have to be
>careful when converting between naive time and UTC (or anything else
>that has a concept of timezone).

(---)

>I'm very tempted to put all the smarts in conversions though: you can
>take a naive datetime object, interpret it in a particular timezone
>using a given DST ruleset (local time and UTC being two common cases)
>and convert it to a timestamp, which has different semantics, but can
>be converted back to naive time by interpreting according to some
>timezone.

(---)

Am I misunderstanding something, or is your "naive time" simply local
time without the knowledge of DST or time zone ?  If so, you have an
excellent solution that works 99.97% of the time.  Unfortunately, once
you have removed the one bit of DST information, it's not always possible
to get it back, without knowing _which_ 2:30 Sunday morning...

	/Paul