pep proposal : A date object for the standard library

[Harald Hanche-Olsen]

+ Chris Barker <chrishbarker at attbi.com>:

| Harald Hanche-Olsen wrote:
| I think that keeping calendrical calculations and time issues
| > strictly separate is a good idea myself.  I would even go so far
| > as to suggest a completely separate module just for dates and
| > calendars. [...]
| 
| I disagree. A Date module that doesn't even understand hours would
| have pretty limited usefulness.

Not at all.  Dates are important.  Interest is still charged by the
day, not by the hour, AFAIK.  And many historical events are tied to
dates more than to the hour.  Similarly with project deadlines.  Most
of the items on my to do list, if they have a deadline associated with
them at all, need to be done before a special date, not some specific
hour or minute on that day.  There must be loads of other examples,
even if you and I can't think of them off-hand.

| > An advantage of this scheme is that a date module
| > has at least a chance of becoming simple enough to become a part of
| > python.  I will make no such assertions about time.
| 
| It has to be both simple and useful. I think it would fail the useful
| test.

I tried to argue against that point above, but I would not at all
suggest we should stop with the dates module:  If a really good one
can be made, it could be a stable foundation on which to build the
time module.  The latter is so tricky and full of pitfalls, you really
need to have nailed down the date part firmly before you even begin
the attempt.

| A DateTime module that doesn't resolve any finer than seconds would
| be very usefull, and I think doable. With all this leap-second
| stuff, resolving finer than that just isn't worth it.

Well, the leap-second stuff is per definition a visible problem at the
seconds level, so you just can't avoid thinking about it.  And once
you know how to deal with seconds, handling sub-second timing is a
totally trivial exercise, hardly worth arguing about.

Even resolving hours can be hard enough, given the way politicians
like to fool around with daylight saving time.  Do you know how to
convert 2008-10-02 14:30 CET to UTC?  I certainly don't.  CET is
Central European time.  By present rules, daylight saving time will be
in effect on that date, so the time would be 2008-10-02 12:30 UTC.
But if politicians change back to the older rule of ending daylight
saving time on the last Sunday of September, or if they abolish
daylight saving time altogether, the right answer is 2008-10-02 13:30
UTC.  What should the module do if you ask it to do the conversion?
It might silently assume today's rule will be in effect, it might
print a warning, or it might raise an exception.  Or it might ignore
the problem altogether, by only allowing numeric time zones, thus
abdicating the responsibility and leaving it up to the application
developer.  I find none of the alternatives really appealing.

Just have a look at Arthur Olson's timezone library some day, and
shudder.  The current version of the zoneinfo files total over 8000
lines - admittedly almost half of it is comments, but this is work you
just don't want to duplicate.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?