Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Re: time, calendar, datetime, etc

 
 
Ben S
Guest
Posts: n/a
 
      07-31-2003
Skip Montanaro wrote:
> kylotan> Is there any chance of these modules becoming somewhat
> combined kylotan> in the future?
>
> Maybe. Perhaps you would like to write a PEP?


I would think that is best left up to those who know what they're
doing... I'm just a newbie who's found date and time handling in Python
to be confusing, and thought I'd mention it. (And I am the original
poster, btw.) If nobody else agrees, maybe it's not really a problem.

> kylotan> Right now it seems a little awkward to find the function
> you kylotan> want. The main culprit is 'timegm' which is the only
> thing I kylotan> need from the calendar module but which should
> probably be in kylotan> the time module.
>
> I've never used it, but it looks like you're right. It's the GMT/UTC
> equivalent of time.mktime(), right?


Possibly... I am not intimately familiar with all the different
functions. It would help if there was some sort of table in the docs
that laid the various time functions side by side for an easy
comparison.

> kylotan> PS. I use 'time.strptime(myTime, '%a %b %d %H:%M:%S
> %Y')' as a kylotan> reverse-asctime(), and was surprised that I
> couldn't find this kylotan> wrapped in a function in any of the
> modules. Maybe such a kylotan> function would be considered for
> future addition?
>
> Seems simple enough to not be needed. What makes asctime() all that
> special?


Well, one could say that its very existence makes it special.
Technically asctime() is redundant as you can achieve the same effect
with time.strftime(). Yet it's in the library. Since time.asctime()
exists as a special case, we're assuming that the use of that particular
string format has some intrinsic merit. In particular, a lot of programs
written in C may use it for logfiles. Therefore it makes sense (to me)
to implement the inverse ("timeasc"?).

--
Ben Sizer
http://pages.eidosnet.co.uk/kylotan




 
Reply With Quote
 
 
 
 
Skip Montanaro
Guest
Posts: n/a
 
      07-31-2003

>> Maybe. Perhaps you would like to write a PEP?


Ben> I would think that is best left up to those who know what they're
Ben> doing... I'm just a newbie who's found date and time handling in
Ben> Python to be confusing, and thought I'd mention it. (And I am the
Ben> original poster, btw.) If nobody else agrees, maybe it's not
Ben> really a problem.

Yeah, but you spoke up. There are probably lots of people willing to
throw stones at^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hcomment on your work, and since
this would largely be a reorganization of existing modules, there wouldn't
be all that much Python knowledge required (except that backwards
compatibility is a requirement for 2.4). In any case, if you have concrete
ideas about how the three should be merged into two, a PEP's the best place
to document it. Your ideas will largely be lost if the python-list archive
is the only place they are recorded.

Ben> Well, one could say that its very existence makes it special.
Ben> Technically asctime() is redundant as you can achieve the same
Ben> effect with time.strftime().

I believe asctime() predates strftime() as a C library function by quite a
bit.

Ben> Yet it's in the library. Since time.asctime() exists as a special
Ben> case, we're assuming that the use of that particular string format
Ben> has some intrinsic merit. In particular, a lot of programs written
Ben> in C may use it for logfiles. Therefore it makes sense (to me) to
Ben> implement the inverse ("timeasc"?).

I couldn't pick an asctime()-generated date out of a lineup. For most
logging I think it makes sense to use sortable numeric dates (ISO-8601).
Besides sortability, they are indifferent to language and unambiguous.
There are many little variations in "human readable" dates, even those which
are so-called standards. Someone always gets things "wrong". Quick, what's
the format of an RFC-822 date? Is it the same as an RFC-2822 date? What
about RFC-1036? RFC-850?

Not that I have any claim to have been complaining loud and clear about this
problem back in 1982 and 1983 when these RFC were written (or earlier, when
the systems they codified were first developed), but I don't think there's
any use in further propagating arcane date formats.

Skip


 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      07-31-2003

"Skip Montanaro" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>


>
> I couldn't pick an asctime()-generated date out of a lineup. For most
> logging I think it makes sense to use sortable numeric dates (ISO-8601).
> Besides sortability, they are indifferent to language and unambiguous.
> There are many little variations in "human readable" dates, even those

which
> are so-called standards. Someone always gets things "wrong". Quick,

what's
> the format of an RFC-822 date? Is it the same as an RFC-2822 date? What
> about RFC-1036? RFC-850?
>
> Not that I have any claim to have been complaining loud and clear about

this
> problem back in 1982 and 1983 when these RFC were written (or earlier,

when
> the systems they codified were first developed), but I don't think there's
> any use in further propagating arcane date formats.


Amen, brother!

John Roth
>
> Skip
>
>



 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      07-31-2003

"A.M. Kuchling" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Thu, 31 Jul 2003 08:06:29 -0500,
> Skip Montanaro <(E-Mail Removed)> quoted:
> > Ben> doing... I'm just a newbie who's found date and time handling

in
> > Ben> Python to be confusing, and thought I'd mention it. (And I am

the
> > Ben> original poster, btw.) If nobody else agrees, maybe it's not
> > Ben> really a problem.

>
> It's also not very hard to write a PEP; start with an existing PEP for the
> headings, and skim PEP 1 for the PEP life cycle.
>
> Parsing of date/time formats is the big omission from 2.3's date support

and
> the big advantage that mxDateTime still has. With 2.3 you still have to
> roll your own parser for ISO-8601 format or whatever. Fixing the rfc822
> module is probably the largest problem; we can't just change getdate() to
> return a datetime instead of a 9-tuple, so it'll have to be supported as a
> new method. The standard library should probably use datetime as much as
> possible, but backwards-compatible 9-tuple-based interfaces will still

need
> to be supported.


The datetime module is a great piece of work, but I wonder why it
wasn't made more compatible with the time module? It would seem to
be simple enough to provide a sequence interface so the object
supports the 9-tuple directly (for either naive or tz-aware, pick one,)
and also supports the same attributes as the objects in the time package.

I also wonder why anyone made the choice to set the year origin at
1AD? That decision, by itself, makes it almost unusable for my hobby
(astrological software, which is basically astronomical software
with a different focus.) Astronomical dates are always measured
in days since 4700 and something BC. History did not begin, after
all, six years after JC was born. (And astronomical years, btw,
do include a year zero, which historical years do not.)

Other than that, and a couple of other bobbles (depending on the
C library for strftime(), and the lack of an input parser both come
to mind) it's a great piece of work.

John Roth


>
> --amk (www.amk.ca)
> Hello! I'm the Doctor. I believe you want to kill me.
> -- The Doctor, in "Silver Nemesis"



 
Reply With Quote
 
Andrew Dalke
Guest
Posts: n/a
 
      08-01-2003
John Roth:
> I also wonder why anyone made the choice to set the year origin at
> 1AD? That decision, by itself, makes it almost unusable for my hobby
> (astrological software, which is basically astronomical software
> with a different focus.) Astronomical dates are always measured
> in days since 4700 and something BC.


Well, if you're doing astronomical time, wouldn't you just add 4700
and something years and 12 hours (as I recall, astronomers have a
12 hours offset because they observe at night and don't want to have
to change the date (or forget to change the date) part way though.)
How is that unusable?

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.

And as for unusable, bah. The nuances of time are very sublte.
Ivan Van Laningham at the Houston conference ('98, I think) gave
a paper on using Python for the Mayan calendar. Even if Python
were to use astronomical time as its basis, that code wouldn't handle
his needs - eg, he wanted to know when the Mayan calendar repeats
itself. Answer? Once every
25494650485744703215685398702235039653929343907714 49170872386445565969718817
5919250180245133376000
years. His paper is at
http://www.foretec.com/python/worksh...pers/laningham
/laningham.html
and it was a very enjoyable talk.

For another example, to be really precise, a datetime module needs
to support leap seconds, so that "23:59:60" is, at times, valid. But
Python's datetime module doesn't allow that.

And if it did, it would almost certainly break code written by people
who didn't know there could be 61 seconds in a minute.

So in summary, almost no one needs the functionality beyond what
the standard library has, supporting each and every specialized niche
makes for more complex code, and more complex code means people
who do "normal" programming are much more likely to run into problems
and make the code more likely to break.

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


 
Reply With Quote
 
M.-A. Lemburg
Guest
Posts: n/a
 
      08-01-2003
John Roth wrote:
> The datetime module is a great piece of work, but I wonder why it
> wasn't made more compatible with the time module? It would seem to
> be simple enough to provide a sequence interface so the object
> supports the 9-tuple directly (for either naive or tz-aware, pick one,)
> and also supports the same attributes as the objects in the time package.
>
> I also wonder why anyone made the choice to set the year origin at
> 1AD? That decision, by itself, makes it almost unusable for my hobby
> (astrological software, which is basically astronomical software
> with a different focus.) Astronomical dates are always measured
> in days since 4700 and something BC. History did not begin, after
> all, six years after JC was born. (And astronomical years, btw,
> do include a year zero, which historical years do not.)


FWIW, mxDateTime has all needed features for these things (and has
had them for years).

--
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source (#1, Aug 01 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

__________________________________________________ ______________________


 
Reply With Quote
 
Ben Finney
Guest
Posts: n/a
 
      08-01-2003
On Thu, 31 Jul 2003 22:47:27 -0600, Andrew Dalke wrote:
> Why would supporing you be reasonable to the other 99+% of the
> users who don't care about doing astronomical measurements


It is astronomy (and, before it, astrology) that has driven the
standardisation of time for many centuries; anyone wanting to use a
standardised time system is using one based on astronomical imperatives.

> even about the "was there a year 0?" debate.


Anyone who wants to deal with dates BC (in the Gregorian calendar) cares
about the "was there a year 0?" question (answer: not in the Gregorian
calendar, there wasn't).

So it seems you're dismissing a large sector of users: those who deal
with dates before 1AD, and those who want to use worldwide date/time
standards.

> Python's datetime module doesn't allow [more than 60 seconds in a
> minute].
> And if it did, it would almost certainly break code written by people
> who didn't know there could be 61 seconds in a minute.


Such people would run into trouble when leap seconds occurred anyway;
keeping the datetime module ignorant of it just means the problems will
not be dealt with when the program is designed (when it is easy to
correct) but rather be thrust in their face when a leap second occurs
(presumably when the program has been long forgotten about and the
original programmer possibly departed).

> So in summary, almost no one needs the functionality beyond what the
> standard library has, supporting each and every specialized niche
> makes for more complex code, and more complex code means people who do
> "normal" programming are much more likely to run into problems and
> make the code more likely to break.


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.

--
\ "Anything that is too stupid to be spoken is sung." -- Voltaire |
`\ |
_o__) |
Ben Finney <http://bignose.squidly.org/>
 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      08-01-2003

"Andrew Dalke" <(E-Mail Removed)> wrote in message
news:bgcr5a$8ac$(E-Mail Removed)...
> John Roth:
> > I also wonder why anyone made the choice to set the year origin at
> > 1AD? That decision, by itself, makes it almost unusable for my hobby
> > (astrological software, which is basically astronomical software
> > with a different focus.) Astronomical dates are always measured
> > in days since 4700 and something BC.

>
> Well, if you're doing astronomical time, wouldn't you just add 4700
> and something years and 12 hours (as I recall, astronomers have a
> 12 hours offset because they observe at night and don't want to have
> to change the date (or forget to change the date) part way though.)
> How is that unusable?


Because I need to be able to deal with BC dates, obviously. Fudging
the base date won't handle that.

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

> And as for unusable, bah. The nuances of time are very sublte.
> Ivan Van Laningham at the Houston conference ('98, I think) gave
> a paper on using Python for the Mayan calendar. Even if Python
> were to use astronomical time as its basis, that code wouldn't handle
> his needs - eg, he wanted to know when the Mayan calendar repeats
> itself. Answer? Once every
>

25494650485744703215685398702235039653929343907714 49170872386445565969718817
> 5919250180245133376000
> years. His paper is at
>

http://www.foretec.com/python/worksh...pers/laningham
> /laningham.html
> and it was a very enjoyable talk.


There are a number of "Mayan" calendars; it's a very complicated
subject. I had no objection to using the proleptic Gregorian calendar
for display: you have to use something, and that's almost universally
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. 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.

>
> For another example, to be really precise, a datetime module needs
> to support leap seconds, so that "23:59:60" is, at times, valid. But
> Python's datetime module doesn't allow that.


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 if it did, it would almost certainly break code written by people
> who didn't know there could be 61 seconds in a minute.


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.

> So in summary, almost no one needs the functionality beyond what
> the standard library has, supporting each and every specialized niche
> makes for more complex code, and more complex code means people
> who do "normal" programming are much more likely to run into problems
> and make the code more likely to break.


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.

John Roth
>
> Andrew
> (E-Mail Removed)
>
>



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

"Christopher Koppler" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Thu, 31 Jul 2003 22:49:28 -0400, "Tim Peters" <(E-Mail Removed)>
> 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



 
Reply With Quote
 
Andrew Dalke
Guest
Posts: n/a
 
      08-01-2003
Ben Finney:
> It is astronomy (and, before it, astrology) that has driven the
> standardisation of time for many centuries; anyone wanting to use a
> standardised time system is using one based on astronomical imperatives.


And here I thought it was the railroads which drove the standarization.
Before then, each city had its own noon, and the only standarization
between places was for dates. (Except also depending on your faith.)
Granted, "noon" is an astronomical measurement, just that the actual
time changed from place to place.

Kinda depends on what you call "standard". And before trains,
ships wanted to know the time to know the location, and monks
wanted to know when to pray, and ..

So again I say, most people don't care that much about the time.
A useful library doesn't need to incorporate all the details needed by
astronomers, historians, etc.

> Anyone who wants to deal with dates BC (in the Gregorian calendar) cares
> about the "was there a year 0?" question (answer: not in the Gregorian
> calendar, there wasn't).
>
> So it seems you're dismissing a large sector of users: those who deal
> with dates before 1AD, and those who want to use worldwide date/time
> standards.


That's not in disagreement with what I said. I said (though more
loosely) 99+% of the people who are affected by the restrictions of
datetime won't notice a problem. The remaining <1% might still be
"a large sector of users". For them I say, develop a library which
deals with all that complexity (or use the mx package).

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.

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

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?

> keeping the datetime module ignorant of it just means the problems will
> not be dealt with when the program is designed (when it is easy to
> correct) but rather be thrust in their face when a leap second occurs
> (presumably when the program has been long forgotten about and the
> original programmer possibly departed).


Easy to correct? Okay, the last leap second was added 1/1/99. Did
you upgrade some data file then to include that change? Or did your
software fix itself automatically? Or did you just synch your machine
to network time and figure it was part of normal clock skew?


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

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.

Ahhh, I shoulda been a philosopher.

Andrew
(E-Mail Removed)


 
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