Python time class

[Werner Geuens]

I'd like to run a few questions and suggestions by you people, mainly about
the time class.

You may have noticed that at least one function - strptime() - doesn't work
on at least one platform.
Yes, THAT platform.
I don't like it any more than anyone here, I'm sure. But as many amongst
you, I also HAVE to use it to get paid.
Now, the function strptime() is just an example.

As someone pointed out, reducing everything to the least common denominator
will get you a language that is of very little use.
Another opinion I read was that if someone wants to run Python on a
braindead platform, wel...

I beg to differ with the second point of view.
I don't think we have to trade in functionnality to platform independance.
Nor that it's acceptable to have less functionality on some platforms.
The platform independant nature of Python is amongst the most important
arguments for it's use as a general purpose programming tool.
And where I agree that building parts of Python on underlaying C functions
reduces pointless overhead, I don't see that as an excuse not to make sure
the base language features and classes run on every implementation. Even on
Windows. Where C functions are absent, it's easy enough to compensate for
that in the platforms binairies.

That's point 1: getting Python basics to work the same way on every
platform, even the EVIL ones.  :-)

Now for point 2.
I don't like the time class. At all. It's all very well to base a time class
on it's equivalent of C functions. It reduces the volume of Python-specific
code. They exist. But then, so do steam engines.
The functions in time.h has never really striked me as very practical,
complete or even usefull. (ducking and running from the system's programmers
bunch... NOT!!!)

I'd like to see a complete rewrite of the time class. It should be
independant of the notion of system time, and provide a simple usefull
interface. Why does a modern time class supposes the universe started in
1970? Why can't a lapse of time be expressed in something more precise than
seconds? Why should time stop in 2038 ?

The internal format may be seperate for date and time, or one class for
both. Maybe a date object, a time object, and a datetime object to integrate
both.

Efforts should be made to:
- render it independant of the underlying "time.h" mess of the platform
- keep away from notions related to systems, OS's or programming languages
(no epoch, no one-numeric-format-fits-all, no 32 bit limits, define
precision independantly from those of system clocks)
- stay with one calendar, but allow hooks for input/output with others
(jewish, arabic, chinese,...)
- don't worry about weird date jumps in the past, but enable such jumps to
be defined later on
- see to it that all operations between date, time and datetime are possible
  (ie: substract a time from a date, and receive a datetime where a time of
0:00 is supposed for the initial date)
- get the new time class to replace the actual, no point in adding yet
another external class
- write a max of source in python, write C only if really an advantage
(performance really an issue?)

Exampe of a pointless approach: the actual time-tuple takes year, month,
day, hours, min and sec. But also day of week. If date and time are provided
at imput, why ask to provide day of week? And why is it allowed to enter a
day of week not related to the date? Monday 18/5/2001 is accepted as input,
when it should be friday. Ludicrous !


I know: the proposal is not very clear yet. But in a nutshell: what do you
think about designing/writing a new, clean, logical, platforms-independant
date/time class and propose for it to be included as the base time class in
a future release of Python?

I don't pretend to be able to write this in whole, I'm better at designing
the base principals. But I'd be willing to give it a go.

Of course, if no one cares for the idea, I'll just crawl back into lurking
mode.