Greetings! Is there any reason for not having a single keyword parameter for every function accepting a tzinfo instance? I've noticed that some require 'tz', and others 'tzinfo'. Is it too late to fix that? Also, is there any further work going on to improve the datetime module? I'm not suggesting we should mirror mx.DateTime functionalities, but two features I miss from mx.DateTime is the DateFrom(), which does its best to parse a given string, and the RelativeDateTime() functionality. This has probably been raised in the past, so if that's the case, I'm sorry. Marc-Andre, what's your opinion about reusing code from mx.DateTime into datetime? Anyway, reusing code or not, I'll probably put sometime on it in the future, if this looks interesting to everyone (after I finish my current python pendencies, like SRE's recursivity removal). -- Gustavo Niemeyer http://niemeyer.net
[Gustavo Niemeyer]
Is there any reason for not having a single keyword parameter for every function accepting a tzinfo instance?
Just the lack of anyone pointing it out in the module's 18-month review process <wink>.
I've noticed that some require 'tz', and others 'tzinfo'. Is it too late to fix that?
Of course, although it's not too late to add synonyms. It appears that the functions "with a lot of arguments" use tzinfo, and those with only one or two arguments tz now. I doubt anyone would bother to use the tz keyword-arg name for a few-argument function (now(), fromtimestamp(), astimezone()), so I'd rather that those few grow a tzinfo synonym. tz can be deprecated too, if you're bold.
Also, is there any further work going on to improve the datetime module?
Not that I'm aware of. I'm not working on it anymore (other than keeping my out for bug reports, of which there have been blessedly few).
I'm not suggesting we should mirror mx.DateTime functionalities, but two features I miss from mx.DateTime is the DateFrom(), which does its best to parse a given string, and the RelativeDateTime() functionality.
This has probably been raised in the past, so if that's the case, I'm sorry. Marc-Andre, what's your opinion about reusing code from mx.DateTime into datetime?
Anyway, reusing code or not, I'll probably put sometime on it in the future, if this looks interesting to everyone (after I finish my current python pendencies, like SRE's recursivity removal).
If Guido wanted to stay out of the relatively clear <snort> time zone business, I can imagine his interest in trying to guess how to parse date and time strings. Apart from Brett's strptime(), I believe the email module has some useful string->datetime code. It may be good to fold such stuff in this area as Python already supports into datetime somehow.
On Sun, 14 Sep 2003 20:35:35 -0400, Tim Peters
If Guido wanted to stay out of the relatively clear <snort> time zone business, I can imagine his interest in trying to guess how to parse date and time strings. Apart from Brett's strptime(), I believe the email module has some useful string->datetime code.
The PyXML package includes a parser (xml.utils.iso8601) for the date/time format most commonly used in XML applications. That and a parser for RFC822 dates would meet the needs of many technical applications (though not ones where users can enter dates -- but that problem may be too complicated for the stdlib). I'll happily convert the iso8601 module for addition to the standard library if date parsing is deemed a topic of interest. --amk
On Mon, 2003-09-15 at 08:42, A.M. Kuchling wrote:
I believe the email
module has some useful string->datetime code.
The PyXML package includes a parser (xml.utils.iso8601) for the date/time format most commonly used in XML applications. That and a parser for RFC822 dates would meet the needs of many technical applications (though not ones where users can enter dates -- but that problem may be too complicated for the stdlib). I'll happily convert the iso8601 module for addition to the standard library if date parsing is deemed a topic of interest.
Yep, I think email._parseaddr.parsedate{,_tz}() is an RFC 2822 compliant date parser. Note that there's also Unix-from dates which are slightly different. I'd also like to see factored out various date formating functions, so that the module is more or less symmetric. -Barry
On 15 Sep 2003 09:14:17 -0400, Barry Warsaw
I'd also like to see factored out various date formating functions, so that the module is more or less symmetric.
Probably this is PEP territory. Unless someone else wants to do it, I'll volunteer to produce a draft PEP for adding parsing and formatting functions. --amk
I'd also like to see factored out various date formating functions, so that the module is more or less symmetric.
Probably this is PEP territory. Unless someone else wants to do it, I'll volunteer to produce a draft PEP for adding parsing and formatting functions.
Please, don't discard the generic parser in the PEP. -- Gustavo Niemeyer http://niemeyer.net
If Guido wanted to stay out of the relatively clear <snort> time zone business, I can imagine his interest in trying to guess how to parse date and time strings. Apart from Brett's strptime(), I believe the email module has some useful string->datetime code.
The PyXML package includes a parser (xml.utils.iso8601) for the date/time format most commonly used in XML applications. That and a parser for
Cool! Thanks for mentioning it!
RFC822 dates would meet the needs of many technical applications (though not ones where users can enter dates -- but that problem may be too complicated for the stdlib).
I do not agree. I've done a small research and there seems to be many nice generic implementations of these parsers, which would benefit technical applications *and* hand made dates (some of them below[1]), and it doesn't look that complex. I'll be working to provide trial implementation collecting the best features described in these papers in the near future. Btw, the relativedelta is mostly ready. That's the first step to provide relative dates in the parser.
I'll happily convert the iso8601 module for addition to the standard library if date parsing is deemed a topic of interest.
I'm not yet sure if date parsing and other improvements in the date/time area is a topic of general interest, but at least I am interested. :-) [1] http://www.egenix.com/files/python/mxDateTime.html http://ringmaster.arc.nasa.gov/tools/time_formats.html http://www.thinkage.ca/english/gcos/expl/b/lib/0tosec.html http://search.cpan.org/author/MUIR/Time-modules-2003.0211/lib/Time/ParseDate... -- Gustavo Niemeyer http://niemeyer.net
[Gustavo Niemeyer]
Is there any reason for not having a single keyword parameter for every function accepting a tzinfo instance?
Just the lack of anyone pointing it out in the module's 18-month review process <wink>.
Would you belive that I was.. erm.. sleeping!? :-)
I've noticed that some require 'tz', and others 'tzinfo'. Is it too late to fix that?
Of course, although it's not too late to add synonyms. It appears that the functions "with a lot of arguments" use tzinfo, and those with only one or two arguments tz now. I doubt anyone would bother to use the tz keyword-arg name for a few-argument function (now(), fromtimestamp(), astimezone()), so I'd rather that those few grow a tzinfo synonym. tz can be deprecated too, if you're bold.
It'd be nice to have these synonyms. I'll put it in my ever growing todo list.
Also, is there any further work going on to improve the datetime module?
Not that I'm aware of. I'm not working on it anymore (other than keeping my out for bug reports, of which there have been blessedly few).
I'm not suggesting we should mirror mx.DateTime functionalities, but two features I miss from mx.DateTime is the DateFrom(), which does its best to parse a given string, and the RelativeDateTime() functionality.
This has probably been raised in the past, so if that's the case, I'm sorry. Marc-Andre, what's your opinion about reusing code from mx.DateTime into datetime?
Anyway, reusing code or not, I'll probably put sometime on it in the future, if this looks interesting to everyone (after I finish my current python pendencies, like SRE's recursivity removal).
If Guido wanted to stay out of the relatively clear <snort> time zone business, I can imagine his interest in trying to guess how to parse date and time strings. Apart from Brett's strptime(), I believe the email module has some useful string->datetime code. It may be good to fold such stuff in this area as Python already supports into datetime somehow.
Cool. I'll give it a try as well. I have a working relativedelta implementation now. I'll polish it a little further and publish it somewhere for tests. Thanks! -- Gustavo Niemeyer http://niemeyer.net
Gustavo Niemeyer wrote:
Also, is there any further work going on to improve the datetime module? I'm not suggesting we should mirror mx.DateTime functionalities, but two features I miss from mx.DateTime is the DateFrom(), which does its best to parse a given string, and the RelativeDateTime() functionality.
This has probably been raised in the past, so if that's the case, I'm sorry. Marc-Andre, what's your opinion about reusing code from mx.DateTime into datetime?
The mxDateTime code comes under the eGenix Public License, so reuse is permittted under the terms of the license. That said, I doubt that you want to maintain a date/time parser in the Python core -- I certainly don't :-)
Anyway, reusing code or not, I'll probably put sometime on it in the future, if this looks interesting to everyone (after I finish my current python pendencies, like SRE's recursivity removal).
-- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Sep 16 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
The mxDateTime code comes under the eGenix Public License, so reuse is permittted under the terms of the license. That said, I doubt that you want to maintain a date/time parser in the Python core -- I certainly don't :-)
Thanks. I've got the relativedelta type ready. It's based on your specification (thanks for it), but uses no code from your module (you'll notice that clearly when looking at the code). Indeed, it has even a different algorithm, which solves some of the current "problems" with your implementation (like getting 03/03 when adding one month to 31/01). You're free to adopt it, if you feel like so. I'll be releasing that code under the PSF license. I'll probably work on a generic parser, once I get some more time. Depending on the results, I'll submit it for review and possible inclusion as well. Here is the documentation of relativedelta, FWIW: """ The relativedelta type is based on the specification of the excelent work done by M.-A. Lemburg in his mx.DateTime extension. However, notice that this type does *NOT* implement the same algorithm as his work. Do *NOT* expect it to behave like mx.DateTime's counterpart. There's two different ways to build a relativedelta instance. The first one is passing it two date/datetime classes: relativedelta(datetime1, datetime2) And the other way is to use the following keyword arguments: year, month, day, hour, minute, seconds, microseconds: Absolute information. years, months, weeks, days, hours, minutes, seconds, microseconds: Relative information, may be negative. weekday: Tuple with (wday, nth), specifying the nth relative weekday. Here is the behavior of operations with relativedelta: 1) Calculate the absolute year, using the 'year' argument, or the original datetime year, if the argument is not present. 2) Add the relative 'years' argument to the absolute year. 3) Do steps 1 and 2 for month/months. 4) Calculate the absolute day, using the 'day' argument, or the original datetime day, if the argument is not present. Then, subtract from the day until it fits in the year and month found after their operations. 5) Add the relative 'days' argument to the absolute day. Notice that the 'weeks' argument is multiplied by 7 and added to 'days'. 6) Do steps 1 and 2 for hour/hours, minute/minutes, second/seconds, microsecond/microseconds. 7) If the 'weekday' argument is present, calculate the weekday, with the given (wday, nth) tuple. wday is the index of the weekday (0-6, 0=Mon), and nth is the number of weeks to add forward or backward, depending on its signal. Notice that if the calculated date is already Monday, for example, using (0, 1) or (0, -1) won't change the day. """ And here is a little demo:
from dtutil import *; from datetime import *
relativedelta(datetime.now(),datetime(1983,9,10,10,00)) relativedelta(years=+20, days=+6, minutes=+25, seconds=+4, microseconds=+231402)
datetime(1983,9,10,10,00)+relativedelta(years=+20, days=+6, minutes=+25, seconds=+4, microseconds=+231402) datetime.datetime(2003, 9, 16, 10, 25, 4, 231402)
relativedelta(datetime(2000,2,29),datetime(2001,3,29)) relativedelta(years=-1, months=-1) datetime(2001,3,29)+relativedelta(years=-1, months=-1) datetime.datetime(2000, 2, 29, 0, 0) relativedelta(datetime(2000,2,29),datetime(2001,3,30)) relativedelta(years=-1, months=-1) datetime(2001,3,30)+relativedelta(years=-1, months=-1) datetime.datetime(2000, 2, 29, 0, 0)
relativedelta(datetime(2000,2,29),datetime(2001,2,28)) relativedelta(months=-11, days=-28) relativedelta(datetime(2000,2,28),datetime(2001,2,28)) relativedelta(years=-1) relativedelta(datetime(2000,2,27),datetime(2001,2,28)) relativedelta(years=-1, days=-1)
relativedelta(datetime(2001,2,28),datetime(2000,2,29)) relativedelta(years=+1) relativedelta(datetime(2001,2,28),datetime(2000,2,28)) relativedelta(years=+1) relativedelta(datetime(2001,2,28),datetime(2000,2,27)) relativedelta(years=+1, days=+1)
import calendar date.today()+relativedelta(weekday=(calendar.MONDAY, +2)) datetime.date(2003, 9, 29) date.today()+relativedelta(weekday=(calendar.MONDAY, -1)) datetime.date(2003, 9, 15)
-- Gustavo Niemeyer http://niemeyer.net
participants (5)
-
A.M. Kuchling -
Barry Warsaw -
Gustavo Niemeyer -
M.-A. Lemburg -
Tim Peters