Python time class

[Eddie and Babs]

I have always thought that the computing world lacks a mature and 
"standard", yet powerful model of time. I find it amazing that modern
high-level languages like Python don't have time literals and built-in
support for time calculations (we do, after all, have built-in support for
complex number calculations, which are surely far less common than time
calculations).

The operative words here are "model of time". Any particular
language's/library's implementation of a data structure is only as good as
the conceptual model on which it is based. We have had to wait until Python
(or at least until Icon, I think) to finally have a superb "holy grail"
model of array/string subscripting. This is clearly the work of someone who
has gathered nuggets of experience and insight from other attempts (eg,
simple 0-based arrays; the left/right/mid functions of Basic) and then
really thought about how all the best bits could be combined.

Once a good time model exists, it will be largely independent of language
and platform (and it would be typically Pythonic to have a Python version
and also a C version for those who value the extra speed; if the model is
sufficiently satisfying, then people will love to implement it in as many
ways as possible).

A good time class would be another first for Python, but I suspect we will
have to wait for another language to come along to do for time what Python
did for subscripts.

&.

PS - perhaps this would be a good subject for a new SIG? I'm sure I and many
others might have some ideas to contribute...




----------
In article <J4eN6.689$RA.127251 at afrodite.telenet-ops.be>, "Werner Geuens"
<wgeuens at pandora.be> wrote:


> 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.
>
>