Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: time, calendar, datetime, etc

Reply
Thread Tools

Re: time, calendar, datetime, etc

 
 
Andrew Dalke
Guest
Posts: n/a
 
      08-01-2003
John Roth:
> Because I need to be able to deal with BC dates, obviously. Fudging
> the base date won't handle that.


Ahhh, I see. I figured you just had dates in Julian, and algorithms
for dealing with dates in Julian, so what you needed was the
ability to deal with present dates (within a few decades at most)
and not define some date in history.

Just to point out though, before 2.3 you couldn't have used Python's
libraries for that either, since the C epoch doesn't handle dates
before 1970. Instead, you would have used mxDateTime, which
does a good job at this, and still does.

> > Why would supporing you be reasonable to the other 99+% of the
> > users who don't care about doing astronomical measurements, nor
> > even about the "was there a year 0?" debate.

>
> Mostly because I don't see a particular reason for the actual
> decision tha was reached.


To be complete, a datetime library needs to handle a *lot* of details.
That makes the library hard to implement and maintain. Eg,
what about the days that 'disappeared' between Julian and Gregorian,
leap seconds, and other worries? Most people don't need that.
For them and me, datetime is good enough. The datetime module
needs a 0 point (the creation of the universe being rather long ago
and the exact time not well known). Given the questions of "when
is year 0?" in different calendar systems, it's easy for me to
understand why Jan. 1st, 1AD is a good starting point. (Easier
than Jan 1st, 1970 - I prefered the Mac's epoch of 1900.)

> used. If you do any kind of historical research, you suddenly discover
> that what you thought you knew about dates doesn't work in practice,
> even in Western Europe.


Well, I don't do historical research. I'm pretty insular that way. I
know there are problems in interpreting dates - my religious training
taught me that if nothing else.

> This is why astronomical dating is important:
> it provides a single, well understood and accepted dating system that
> can be tied to the (unfortunatelly rare) comments about astronomical
> phenomena, and it goes back far enough that all dates of historical
> interest are positive numbers.


Understood. I still maintain that a library which handles all the
specialized datetime issues (historical, religious, astronomical,
navigation, ...) is too complex for inclusion in Python's standard
library. Specialists should use a specialist's library. What Python
has is quite good enough for just about everyone's needs.

Put it this way - FixedPoint still isn't part of Python's standard
library even though it's very important for people dealing with
money. Then again, for most people, floats (!) are good enough.

> Usually, that's handled by a separate conversion from UT (Universal
> Time) to ET (Ephemeris time.) And leap seconds are a modern innovation:
> for accuracy there are a number of correction formulae that you apply
> depending on the exact historical era in question.


And it makes sense for Python's standard library to handle all
that?

> Funny about that: the Unix system specifications that I've seen
> have always said that there may be 61 seconds in a minute. It's built
> into the API.


And there's where I learned it from. Doesn't mean the libraries
support it. And I'm told the C spec's comment about "double leap
seconds" is based on a misunderstanding and those don't actually exist.

One of the reasons for Python to do it's own datetime code is because
of the broken nature of many platforms native time functions.

> Andrew, you've brought in an army of straw men. The **ONLY**
> thing I was criticising was the decision to limit the module to dates
> beginning with 1 AD. All the other things you bring up are things that
> I either don't care about, or that I agree shouldn't complicate the API.


Then you misunderstand my comments. You have a very specialized
need to handle dates before 1AD. Others have a specialized need to
handle leap seconds. Others need to deal with differences between
UTC, UT1, GPS, and other time systems. Still others need to handle
complicated timezones (like "double daylight savings", which I think
datetime doesn't handle). Others again need better than microsecond
timestamps. For all I know, some need a general relativity
compensation term.

To handle all of these and maintain them as the various time standards
change requires effort. There aren't all that many people working
on Python. They decided that most people only need what I termed
'vernacular' time in a previous post in this thread, and that time
system works for 99+% of the datetime needs in the world, and that's
what they implemented. And I commend the developers for defining
what "good enough" means, and defering perfection to other libraries
and future inclusion. Very Pythonic.

Andrew
http://www.velocityreviews.com/forums/(E-Mail Removed)


 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      08-01-2003

"Andrew Dalke" <(E-Mail Removed)> wrote in message
news:bgejrq$i54$(E-Mail Removed)...
> Ben Finney:


[...]

> Python doesn't try to support all numerical systems - that's why
> Numeric exists. Would those users like Numeric support in core
> Python? Probably. Are there more Numeric users than people
> who need a detailed datetime library? Almost certainly yes. So
> I aks again, what makes datetime with B.C. support, leap seconds,
> etc. important enough to justify inclusion in Python's standard library.
>
> By comparison, a friend of mine mentioned that the Java time library,
> which does try to include all these complexities, has gone through
> several iterations to get where it is now and is complicated to use
> because it tries to get all the details right.


Several turns out to be one revision, and I don't think that they
got it right either. From what I see, the Python datetime library
is actually more complicated than the Java library: it's certainly
got more classes, although they seem to be better designed.

>
> > Such people would run into trouble when leap seconds occurred anyway;

>
> Ha! None of my code ever used leap seconds, and in my 15 years
> or so of software development, no one ever filed a bug report on it.
> And on the plus side, I don't have to distribute an update when there
> is an new leap second. That's because for just about everyone in the
> world, a difference of a few seconds doesn't make a difference.
> C'mon - the clocks in my house are +/- a few minutes!


For the most part, the applications that need to be aware of leap
seconds are the ones that communicate with other servers that
are aware of leap seconds, and can report them. As far as I'm
aware, leap seconds are a thing of the past anyway: they proved
to be more trouble than they were worth to anyone.

> It's only the very small number of people who care about the differences
> between UTC, UT1, GPS, TAI, and all those other highly specialized
> time systems that care about these sorts of details ("care" == "affects
> them in any meaningful way"), so what's wrong with those people
> developing a specialized library to handle those issues?


Nothing at all - I'd expect to see some sort of an extension to
handle those issues, just as I'd expect to see an extension if you
wanted to use the proleptic Julian calendar, the Chinese calendar,
the civil Moslem calendar, the Jewish calendar, and on and on
and on.

I'd also expect to see some sort of reasonably well thought out framework
where those extensions could simply be plugged in and just work.

> > Quite the reverse. If the standard library supported things like leap
> > seconds, absence-of-year-zero, and Julian dates, it would be wrapped up
> > in one place where programmers could use it without having to know about
> > the implementation complexities.

>
> Implement that library, get people to use it, implement the functionality
> of the datetime module using it, make sure it's maintainable and
> maintained, petition for its inclusion in Python.
>
> Then again, you could just use mxDateTime.
>
> Here's another view of the issue. The datetime module implements what
> I'll call "vernacular" time. That is, time as is understood by most

people.
> 24 hours in a day, 60 minutes in an hour, 60 seconds in a day, 365 days
> in a year except every 4th year (and hazy idea about something strange
> at the century mark, but that's not a problem now). And then there's
> timezones and daylight savings time. (And no thoughts of "double
> daylight savings like the British had during WWII.")
>
> datetime implements vernacular time. There's a lot of code
> which implements vernacular time, because they aren't written
> by experts. To them, 1) datetime makes sense and 2) won't
> ever cause problems in real life.
>
> I am one of those people. I would like to replace my hand-written
> code with a standard library. I want that library to implement *my*
> time system, not the so-called real one developed by experts who
> worry about variations in the Earth's rotation nor about scholars
> who say the first day of the year back in 1000AD was in March.


Where was it in March? [grin]. Answer. It depends on where is.

> So a robust datetime library almost certainly must implement
> this vernacular time system, if only for completeness. Consider
> 'datetime' as the first module for that hypothetical library. It
> definitely is useful as-is. Now we just have to wait for the rest
> of it to be implemented.


I'm certainly not objecting to that. That's the interface to a time
system that everyone expects, and other objectives should quite
properly be implemented by some sort of extensions. My objection
is to exactly one implementation decision: to limit the time range
at 1AD. That is, to use the vernacular, a show-stopper. It means
that the core of the library has to be reworked if you want to deal
with dates before 1AD. It has nothing to do with the external
interfaces, nor does it have anything to do with whether the package
has the ability to use proleptic Julian dates, Chinese dates, Muslim
civil calendar dates, or anything else.

I don't have the time to look into how difficult it would be
to change that. Right now, I'm working on bringing the Python
version of FIT up to the March Java release, and integrating
it with FitNesse. Maybe when I get back to my astrology
programming. My application date package works for what
I need it to do; it just seems that I can't abandon it for the
standard Python library package. [Sigh.]

John Roth

>
> Ahhh, I shoulda been a philosopher.
>
> Andrew
> (E-Mail Removed)
>
>



 
Reply With Quote
 
 
 
 
Andrew Dalke
Guest
Posts: n/a
 
      08-01-2003
John Roth:
> Several turns out to be one revision, and I don't think that they
> got it right either. From what I see, the Python datetime library
> is actually more complicated than the Java library: it's certainly
> got more classes, although they seem to be better designed.


Then I was just spreading rumor.

I see the following classes in Java:
java.util.Date
java.sql.Date
java.sql.Time
java.sql.Timestamp
java.util.Calendar
java.util.GregorianCalendar
java.util.Timezone
java.util.SimpleTimeZone
java.text.DateFormat
java.text.SimpleDateFormat

As for Python ones ...
datetime.timedelta
datetime.date
datetime.datetime
datetime.tzinfo
plus the older ones of
time.*
calendar (mostly useless, IMHO)

> For the most part, the applications that need to be aware of leap
> seconds are the ones that communicate with other servers that
> are aware of leap seconds, and can report them. As far as I'm
> aware, leap seconds are a thing of the past anyway: they proved
> to be more trouble than they were worth to anyone.


But those tools don't need support for BC-era dates...

> I'd also expect to see some sort of reasonably well thought out framework
> where those extensions could simply be plugged in and just work.


There were some dicussions for that - the idea was that datetime and
mxDateTime values should be interoperable. I don't recall the details
of those plans though ... (searching) ... Ahh, a thread starts here
http://mail.python.org/pipermail/pyt...ry/032100.html
but I don't know the conclusion.

> Where was it in March? [grin]. Answer. It depends on where is.


Sure. Which is why datetime support for then is hard.

The statement I made in c.l.py years ago was that it's all dependent
on longitude, lattitude, and additude. Software can handle the first
two, but not the third, at least not without a lot of work and upkeep.

> My objection
> is to exactly one implementation decision: to limit the time range
> at 1AD. That is, to use the vernacular, a show-stopper. It means
> that the core of the library has to be reworked if you want to deal
> with dates before 1AD.


I gave an idea of a way to work around that, by using an offset
of 6000 years. I'll look to there for followup.

> programming. My application date package works for what
> I need it to do; it just seems that I can't abandon it for the
> standard Python library package. [Sigh.]


Does that mean if there was no decision to include datetime in
Python 2.3 then you wouldn't be able to support your application
at all in Python? Or would you have just decided to use mxDateTime?
If the latter, what's preventing you from doing so now?

Andrew
(E-Mail Removed)


 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      08-03-2003
John Roth fed this fish to the penguins on Friday 01 August 2003 04:16
am:


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


Calculated using the J2000 definition, or the B1900 definition?


--
> ================================================== ============ <
> (E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> (E-Mail Removed) | Bestiaria Support Staff <
> ================================================== ============ <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <


 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      08-03-2003

"Dennis Lee Bieber" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> John Roth fed this fish to the penguins on Friday 01 August 2003 04:16
> am:
>
>
> >
> > 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,

>
> Calculated using the J2000 definition, or the B1900 definition?


AFIK, it hasn't changed. I *think* you're talking about the epoch,
which is an astronomical thing that's rightly ignored outside of astronomy.
Even astrologers ignore it: we prefer to know where the vernal equinox
is at date, not where it is at some other date.

John Roth
>
>
> --
> > ================================================== ============ <
> > (E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> > (E-Mail Removed) | Bestiaria Support Staff <
> > ================================================== ============ <
> > Bestiaria Home Page: http://www.beastie.dm.net/ <
> > Home Page: http://www.dm.net/~wulfraed/ <

>



 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      08-03-2003
John Roth fed this fish to the penguins on Sunday 03 August 2003 03:47
am:

>
> AFIK, it hasn't changed. I *think* you're talking about the epoch,
> which is an astronomical thing that's rightly ignored outside of


There is a subtle change in the length of the "year" (besides the
redefinition of where "0/first point of Aries" is with respect to the
stars).

J2000 defines a year as 365.25 days, B1900 used 365.242198781

From "Spherical Astronomy" (Robin M. Green; 1985 Cambridge University
Press)

"... The starting epoch for JD has the same formal definition in every
time-scale, but will not correspond to the same instant of time. ..."

While both use 4713BC Jan 1.5 as the "0" point, the moment that point
occurred differs in the two calculations.

--
> ================================================== ============ <
> (E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> (E-Mail Removed) | Bestiaria Support Staff <
> ================================================== ============ <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <


 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      08-03-2003

"Dennis Lee Bieber" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> John Roth fed this fish to the penguins on Sunday 03 August 2003 03:47
> am:
>
> >
> > AFIK, it hasn't changed. I *think* you're talking about the epoch,
> > which is an astronomical thing that's rightly ignored outside of

>
> There is a subtle change in the length of the "year" (besides the
> redefinition of where "0/first point of Aries" is with respect to the
> stars).
>
> J2000 defines a year as 365.25 days, B1900 used 365.242198781
>
> From "Spherical Astronomy" (Robin M. Green; 1985 Cambridge University
> Press)
>
> "... The starting epoch for JD has the same formal definition in every
> time-scale, but will not correspond to the same instant of time. ..."
>
> While both use 4713BC Jan 1.5 as the "0" point, the moment that point
> occurred differs in the two calculations.


Undoubtedly true, but it makes absolutely no difference for what
we're talking about. All we need in this conversation is a mapping
of days to integers that goes back far enough. Converting from
GMT / UT / whatever to ET is something that can safely be
left to the astronomers, and that's what the detail you're talking
about is concerned with.

John Roth
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: PIL (etc etc etc) on OS X Kevin Walzer Python 4 08-13-2008 08:27 AM
there are too many warnings (you are about to....etc etc forever) after installing Firefox trevor_smithson@yahoo.com Firefox 2 10-13-2005 07:35 PM
user authentication via /etc/passwd|/etc/shadow Marco Herrn Python 7 04-09-2004 12:12 PM
Python Audio (Alpy, Fastaudio, Etc Etc) Daniel Joyce Python 1 09-16-2003 08:39 PM
Is there a standard module library function to access /etc/passwd or /etc/group Robin Cull Python 5 07-31-2003 09:35 PM



Advertisments