time2 might be a good place to include the nifty
Reingold-Dershowitz "rata die" date numbering; it can be
converted back and forth a vast number of widely used calendars:
Julian, Gregorian, Hebrew, old and new Hindu, Chinese (given
enough floating-point accuracy), Astronomical Julian, and
several others.
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.
--- Brett Cannon <bac@OCF.Berkeley.EDU> wrote:
> I have written the callout to strptime.strptime (strptime is
> SF patch
> #474274) as Guido asked. Since that was the current hold-up
> and the
> thread has gone dormant, I figured I should summarize the
> discussion up to
> this point.
>
> 1) what is the need?:
> The question was raised why this was done. The answer was
> that since time
> is just a wrapper around time.h, strptime was not guaranteed
> since it is
> not a part of ANSI C. Some ANSI C libraries include it,
> though (like
> glibc), because it is so useful. Unfortunately Windows and OS
> X do not
> have it. Having it in Python means it is completely portable
> and no
> longer reliant on the ANSI C library being kind enough to
> provide it.
>
> 2) strftime dependence:
> Some people worried about the dependence upon strftime for
> calculating
> some info. But since strftime is guaranteed to be there by
> Python (since
> it is a part of ANSI C), the dependence is not an issue.
>
> 3) locale info for dates:
> Skip and Guido pointed out that calendar.py now generates the
> names of
> the weekdays and months on the fly similar to my solution. So
> I did go
> ahead and use it. But Skip pointed out that perhaps we should
> centralize
> any code that calculates locale info for dates (calendar.py's
> names and my
> code for figuring out format for date/time). I had suggested
> adding it to
> the locale module and Guido responded that Martin had to ok
> that. Martin
> hasn't responded to that idea.
>
> 4) location of strptime:
> Skip asked why Guido was having me write the callout patch to
> timemodule.c. He wondered why Lib/time.py wasn't just created
> holding my
> code and then renaming timemodule.c to _timemodule.c and
> importing it at
> the end of time.py. No response has been given thus far for
> that.
>
> I also suggested a possible time2 where things like strptime,
> my helper
> fxns (calculate the Julian date from the Gregorian date,
> etc.), and things
> such as naivetime could be kept. That would allow time to
> stay as a
> straight wrapper to time.h while all bonus code gets relegated
> to time2.
> Guido said it might be a good idea but would have to wait
> until he got
> back from vacation.
>
>
> That pretty much sums up everything to this point; hope I got
> it right and
> didn't miss anything.
>
> -Brett C.
>
>
>
> _______________________________________________
> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4