[Zope3-dev] The Date Time and TimeZone question

[Tim Peters]

[Tim]
> If you leave it up to the platform, then the answers you get
> depend on the platform you happen to be using

[Lennart Regebro]
> Only if one of the platforms are incorrect.

I don't know how you define correct.  I've pointed you at the relevant
standards, and they simply refuse to define correctness for these matters.
In the absence of a strong standard, there isn't any cross-platform way to
get the same answers short of ignoring whatever facilities the platform may
offer (platforms don't agree in reality -- try it).

It would help if you could name a specific software package you believe does
these things correctly.  For example, you said before that Windows doesn't
deal with historical DST changes, but didn't say whether you believed that
was correct or incorrect.  If you want to interact with JavaScript, you
should be aware that the standard for that language explicitly forbids
correcting for historical DST quirks.  POSIX explicitly forbids injecting
leap seconds, but is silent about historical DST quirks.  And so on.
"Correct" to some people means playing nice with other software systems, and
so there's no one-size-fits-all answer, as other software systems have their
own ideas and established user bases who fight change.

> That incorrectness will more likely than not be because the time zone
> information on one of the systems is not updated. That can happen even
> if the two systems use the time system.  And if one uses a private
> system that noone else is using, it is even more likely that the
> information will be incorrect. And I guess that the system admins will
> be *very* surprised when they update their operating systems zone
> information and python/zope ignores that update.

It seems that your idea of correct is to mimic whatever the platform does.
Is that fair?  I'm not arguing for or against that view, I'm just trying to
clarify what it is you want (while cautioning that if you want the C library
datetime facilities to be consistent across platforms, you're not going to
get that).

> ...
> I don't like arguing, and I dislike fighting. I have shared my thoughts
> on the subject, and unless somebody can tell me exactly what problem
> nobody has solved before that need somebody to reinvent the wheel yet
> another time, then my views on the subject have not changed.

The problem that's never been solved is that people don't agree about what
"correct" is.  In many other areas we can make good progress anyway because
a strong standard just picks a fixed set of answers and calls it correct by
fiat (for example, the 754 floating-point standard eventually supplanted
dozens and dozens of quirky vendor-specific schemes).  There is no such
standard for this field, though.

> Summary and famouts last (ha!) words on this matter:
>
> I think Guidos proposal are excellent, except for two things.
> 1. I don't think adding 24 hours and adding 1 day should amount
>    to the same thing on DST boundaries.
> 2. I don't see the problem with asking the operating system for time
>    zone information when converting between local time an UTC.

About #2, his proposal doesn't cover conversions yet.  The example of a
LocalTime tzinfo object on

    http://www.zope.org/Members/fdrake/DateTimeWiki/TimeZoneInfo

does ask the platform C library about timezone and DST information, although
(as its comments say) it's limited by the platform's mktime() capabilities
(on many platforms, mktime() "doesn't work" for years before 1900, or thinks
1900 is a leap year, etc; I suppose there may even be a platform C library
so broken that mktime() doesn't even work before 1970, although I'm not
aware of any specific one).