Python time class

Eddie and Babs kca17 at dial.pipex.com
Sat May 19 16:01:31 EDT 2001


What I mean by a good "model" of time is a good PROGRAMMING model. I realise
that metrologists already have a rigorously defined time unit in the Second
(and even binary prefixes, unpleasantly named kibi = 1024, mebi = 1048576,
etc, analogous to kilo, mega, etc; horrible names, yes, but they do exist).

As programmers, we have to do calculations with values that represent points
in time. I was not referring to relativistic physical calculations, but
rather to simple things like time and date intervals, etc. Although a well
elaborated and complete system for expressing and calculating with these
values may exist, I have never seen it (not that I am any kind of expert).

However inconvenient it may be for programmers, we obviously can't expect
users to input times into a diary application as 32-bit numbers of seconds
since 1970. So, we provide for hours, minutes and seconds, etc. If we want
to tell the user what will be happening two and a half hours from now, we
could calculate something like:-

        currentTime += (2 * 3600) + (30 * 60)    # Time as seconds

but something along the lines of:-

        currentTime += Hour(2) + Minute(30)

...is surely more legible and no less precise. And time intervals are prone
to "endpoint paranoia" (ie, the interval from 1st July to 7th July; does
this include the 7th July or stop just before it? Answer: it depends what
the programmer had in mind at the time - there is no standard model
generally expected by programmers.) And when someone specifies that
something happened "yesterday" they will generally mean sometime between
0:00 and 23:59, not the exact point in time specified by currentTime -
86400. Need I go on?

This is what I mean by a good model of time. A consistent set of routines,
classes and, most importantly, semantics to support the kinds of
calculations that programmers actually USE day to day. But it will take a
new language I think (Python3K, perhaps?) before such a model becomes
transparent and we can write things like:-

        currentTime += 23h27m

...without even noticing.

&.

PS - you are not at all dense. It's me - nobody seems to understand a word I
write on this newsgroup <(500000000L - 8j) / (1000000000L + 9j) wink>



----------
In article <mailman.990219330.14459.python-list at python.org>,
Eugene.Leitl at lrz.uni-muenchen.de wrote:


> Eddie and Babs wrote:
>>
>> I have always thought that the computing world lacks a mature and
>> "standard", yet powerful model of time. I find it amazing that modern
>
> What do you mean? There is this nifty SI unit called second. And
> a set of prefixes, unfortunately not based on binary orders of magnitude.
>
>> 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).
>
> Huh? What's wrong with
> 10002354235341341223412452353234253450000L *
> 20342345235435335235323452353452352345545235345435L
> for instance?
>
>> The operative words here are "model of time". Any particular
>
> Do you mean Newtonian time, or General Relativity? As an interpreted
> language, I don't think Python needs corrections for travel and spacetime
> curvature...
>
>> Once a good time model exists, it will be largely independent of language
>
> Perhaps I'm a bit dense, but I honestly fail to see your point.
> You don't happen to refer to this completely arbitrary,
> comonnly deprecated 24/7/12/365 chunking scheme?
>
>> 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.
> 



More information about the Python-list mailing list