time, calendar, datetime, etc

John Roth newsgroups at jhrothjr.com
Fri Aug 1 07:16:42 EDT 2003


"Christopher Koppler" <klapotec at chello.at> wrote in message
news:f6ojivk3c87s8memo970n7v0hj6gdb32s4 at 4ax.com...
> On Thu, 31 Jul 2003 22:49:28 -0400, "Tim Peters" <tim.one at comcast.net>
> wrote:
>
> >The time module consists of thin wrappers around C's mish-mash of quirky,
> >platform-dependent time manipulation functions.  We eventually want to
> >pretend the time module never existed <0.9 wink>.  9-tuples are absurd.
>
> No, it's reality that's absurd. C's mish-mash of quirky,
> platform-dependent time manipulation stems from the fact that defining
> a standard way of handling time is difficult when it's
> 1. subject to the platform designers interpretation of what is useful,
> 2. subject to politics and most severely,
> 3. subject to changes in nature.
>
> Leap seconds!

Frankly, if what was wanted was a single, consistent and usable
definition of time, the astronomical Julian date is it. It's a single
number,
absolutely continuous since 4712 BC or thereabouts, and has well
defined conversions to and from the proleptic Gregorian and Julian
calendars. It takes me about two clicks to determine that the current
AJD is 2452852.9650.

Anything else is politics and poor analysis.

The funny thing is, it wouldn't be all that hard to fix. The only
part of the formal API that I can see which is even remotely
affected is the fromordinal() method, and there's no reason to
change it, just to define it as only being effective from 1AD
onwards. All that's needed, really, is a constructor that takes
the AJD, and an extraction method for it. Since the package
doesn't have any string to date conversion routines (presumably
yet,) not even that's affected.

John Roth
>
>
> --Christopher






More information about the Python-list mailing list