Thanks for the amplification - that was precisely my point. When proposing that strptime() parse "Julian" dates, some more precise definition of Julian is required. --- John Machin wrote:

21/06/2002 10:27:22 PM, Steven Lott wrote:

...

Generally, "Julian" dates are really just the day number

within

...

a given year; this is a simple special case of the more general (and more useful) approach that R-D use.

See http://emr.cs.iit.edu/home/reingold/calendar-book/index.shtml

for more information.

AFAICT from perusing their book, R-D use the term "julian-date" to mean a tuple (year, month, day) in the Julian calendar. The International Astro. Union uses "Julian date" to mean an instant in time measured in days (and fraction therof) since noon on 1 January -4712 (Julian ("proleptic") calendar). See for example http://maia.usno.navy.mil/iauc19/iaures.html#B1

A "Julian day number" (or "JDN") is generally used to mean an ordinal day number counting day 0 as Julian_calendar(-4712, 1, 1) as above. Some folks use JDN to include the IAU's instant-in-time.

Some folks use "julian day" to mean a day within a year (range 0-365 *or* 1-366 (all inclusive)). This terminology IMO should be severely deprecated. The concept is best described as something like "day of year", with a specification of the origin (0 or 1) when appropriate.

It is not clear from the first of your sentences quoted above exactly what you are calling a "Julian date": (a) the tuple (given_year, day_of_year) with calendar not specified or (b) just day_of_year. However either answer seems IMO to be an inappropriate addition to the terminology confusion.

Cheers, John

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

===== -- S. Lott, CCP :-{) S_LOTT@YAHOO.COM http://www.mindspring.com/~slott1 Buccaneer #468: KaDiMa Macintosh user: drinking upstream from the herd. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

I am getting more and more frustrated with the way things are going here lately. At this point I would be more than happy to pass off anything that's assigned to me to other people and just unsubscribe from python-dev. I feel like there are enormous contradictions in the way different changes to Python are being addressed. If you want to take over any of these bugs or patches, feel free: 411881 Use of "except:" in modules 569574 plain text enhancement for cgitb 542562 clean up trace.py 474274 Pure Python strptime() (PEP 42) 541694 whichdb unittest >> I would prefer a time.py module be created to hold Brett's strptime >> function. On import, the last thing it would try doing is to import >> * from _time, which would obliterate Brett's Python version if the >> platform supports strptime(). Guido> That's only a good idea if Brett's Python code has absolutely no Guido> features beyond the C version. I don't understand what you mean. Guido's probably gone by now. Perhaps someone can channel him. I am clearly missing something obvious, but I don't see any support for the argument that having the existing time module call out to a separate Python module makes a lot of sense. (Other than the fact that it comes from the BDFL, of course.) If we put Brett's changes into time.py (I'd argue that initially all we want is strptime(), but can live with the other stuff assuming it's tested - after all, it has to go somewhere), then from _time import * at the bottom, the only thing to be eliminated would be his version of strptime(), and only if the platform libc didn't support it. The Gregorian/Julian date stuff would remain. If you don't want them exposed in time, just prefix them with underscores and don't add them to time.all. The original patch http://python.org/sf/474274 was just about adding strptime() to the time module. All PEP 42 asked for was Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. All the other stuff is secondary in my mind to making time.strptime() universally available and should be dealt with separately. If performance isn't a big issue (I doubt it will be most of the time), I can see dropping the C version of time.strptime altogether. I still think the best way to add new stuff which is written in Python to the time module is to have time.py be the front-end module and have it import other stuff from a C-based _time module. Skip

Guido> I guess my objection (of -0 strength) against renaming time to Guido> _time is that you'd have to fix a dozen or so build recipes for Guido> all sorts of exotic platforms. The last time something like this Guido> was done (for new, a much less popular module than time) the Guido> initial change set broke the Windows build, and I think I saw Mac Guido> build changes for this issue checked in today or yesterday. Okay, I can understand that issue. Still, that is a mere ripple compared to the longer term ramifications of taking a wrong turn by adding a strptime module that might turn out to be more-or-less an orphan. You have to consider: * Is strptime even the right name for it? I doubt it. Only us C-heads would think that was a good name. * If you create a strptime (or timeparse or parsedate) module should it really have exposed functions named julianFirst, julianToGreg or gregToJulian? Ignore the studly caps issue (sorry Brett, I don't think they fit in with normal naming practice in the Python core library) and just consider the functionality. Guido> We can avoid all that if the time module calls out to Guido> strptime.py. But it seems to me that it would be an even bigger step to add a new module to Lib, which, as it now sits, would probably only provide a single useful function. >> If we put Brett's changes into time.py (I'd argue that initially all >> we want is strptime(), but can live with the other stuff assuming >> it's tested - after all, it has to go somewhere), then >> >> from _time import * >> >> at the bottom, the only thing to be eliminated would be his version >> of strptime(), and only if the platform libc didn't support it. The >> Gregorian/Julian date stuff would remain. If you don't want them >> exposed in time, just prefix them with underscores and don't add them >> to time.all. Guido> It's not that I don't want to expose them. I haven't seen them, so I Guido> don't know how useful they are. Guido> However (as I have tried to point out a few times now in response Guido> to proposed changes to calendar.py) I plan to introduce the new Guido> datetime type that's currently living in Guido> nondist/sandbox/datetime/, either the Python version or the C Guido> version if we find time to finish it. Right. Which is another reason I think we shouldn't just plop a strptime module into Lib. There is more going on with time issues than just adding time.strptime(). Creating a Python-based time module seems less intrusive to me at the user level than creating new module you will wind up supporting for a long time. >> If performance isn't a big issue (I doubt it will be most of the time), I >> can see dropping the C version of time.strptime altogether. I still >> think the best way to add new stuff which is written in Python to the >> time module is to have time.py be the front-end module and have it >> import other stuff from a C-based _time module. Guido> I hope I can dissuade you from this. Likewise. ;-) It's clear that there is a lot of semi-related stuff going on related to timekeeping and time calculations. Maybe the best course is simply to hold off on Brett's patch for the time being and consider it in the context of the all the other stuff (your datetime object, Brett's Gregorian/Julian functions, etc). Skip

After reading all the email up to this point, [Guido van Rossum]

[Skip]

[snip]

...

* Is strptime even the right name for it? I doubt it. Only us C-heads would think that was a good name.

It's already called strptime in the time module. :-)

I have to agree with Guido on this one. It might only make sense to people who come from C, but it has always been named this in Python. If the decision is made to go with another module for this code, though, then that is a different story.

...

* If you create a strptime (or timeparse or parsedate) module should it really have exposed functions named julianFirst, julianToGreg or gregToJulian? Ignore the studly caps issue (sorry Brett, I don't think they fit in with normal naming practice in the Python core library) and just consider the

I think you're right. I wrote this code originally after my last final ever in college as an undergraduate and so I was just more interested in relaxing and churning out some good code then being overtly proper in fxn naming. =) I will go through and read the Python coding style PEP and clean up my code. [snip] [Big discussion on whether a new module in Lib or just the callout to my Python code from timemodule.c ensued that is beyond my comment since I am so new to this list]

Yes, holding off until I have the time to work on datetime and review Brett's patch seems wise. Apologies for Brett.

It's quite fine with me. I want to see this done right just like everyone else who cares about Python's development. Personally, I am just ecstatic that I am getting to help out in some way. I feel more like a giddy little kid who is helping out some grown-ups with some important project than a recent college graduate. =) Enjoy your vacation, Guido. And don't leave us, Skip! I know I have greatly appreciated your help both on my patch and your input into all the other threads that have been going on as late here. -Brett C.

[Tim Peters]

[Skip Montanaro] [snip]

Cool! Let's do just that much to start, and don't take it as "a reason" to rename the time module either (it really is trivial to add another .py file to Lib! give the name a leading underscore if you want to imply it's a helper for something else).

Sounds good to me. Perhaps this is the best solution for Python 2.3 (goes beta mid-July, right?). If we do this should we leave access to the C version of strptime, or move all calls over to my code? Personally, I say leave it since then any possible differences people might have with their implementation of strptime compared to mine won't affect them. This is not saying that I think there is, though; I have done my best to make sure there is not a deviance. There is also a noticeable performace difference between my implementation and the C version. I have tried to address the best I could by making locale discovery lazy and being able to have the re object used for a format string be returned so as to use that instead of having to recalculate it, but there is still going to be a difference. So basically, I am agreeing with Tim that my module should just be added as Lib/_strptime.py and my callout should just be added to timemodule.c. I will clean up the naming of my helper fxns and add __all__ to only contain strptime to keep it simple. That will get this in for 2.3 and lets this discussion of where time fxns, data types, etc. are going to be in Python. Who would of thought little old me would spark a Timbot response. =) -Brett C.