Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
MRAB wrote: And when someone says January 30, do they really mean the day before the last day of the month? No, no, that's January -2, a *completely* different thing! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
greg g...@cosc.canterbury.ac.nz (g) wrote: g MRAB wrote: And when someone says January 30, do they really mean the day before the last day of the month? g No, no, that's January -2, a *completely* different thing! But for someone else it would be February -2. -- Piet van Oostrum p...@vanoostrum.org WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
On Mon, Oct 12, 2009 at 4:27 AM, Piet van Oostrum p...@cs.uu.nl wrote: greg g...@cosc.canterbury.ac.nz (g) wrote: g MRAB wrote: And when someone says January 30, do they really mean the day before the last day of the month? g No, no, that's January -2, a *completely* different thing! But for someone else it would be February -2. And for still others, it's the last $DAYOFWEEK of the month, which just happened to fall on the 30th. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Piet van Oostrum wrote: greg g...@cosc.canterbury.ac.nz (g) wrote: g MRAB wrote: And when someone says January 30, do they really mean the day before the last day of the month? g No, no, that's January -2, a *completely* different thing! But for someone else it would be February -2. When is February 0? :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Tim Chase wrote: Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. Well, yes, but that's just one way to solve the problem. I guess I'll just add all possible solutions and then let the user decide what's best in some way. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ That's why mxDateTime actually returning a day in March... mx.DateTime.DateTime(2009, 1, 31) + mx.DateTime.RelativeDateTime(months=+1) mx.DateTime.DateTime object for '2009-03-03 00:00:00.00' at 2ba43f93ebe0 That's intuitive for mathematicians only, though ;-) So yes, messy it is! Indeed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Rhodri James wrote: On Fri, 09 Oct 2009 13:39:43 +0100, Tim Chase python.l...@tim.thechases.com wrote: Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ I'd hazard a guess that what we're actually seeing is people mentally rebasing their indices, i.e. counting from the end of the month rather than the start, which makes the last day of January and January 31 not the same thing really. Unfortunately we're very fuzzy about when we do things like this, which makes it hard on a poor programmer. Ah, for that we have RelativeDateTime: # next month, last day of the month mx.DateTime.DateTime(2009, 1, 31) + mx.DateTime.RelativeDateTime(months=+1, day=-1) mx.DateTime.DateTime object for '2009-02-28 00:00:00.00' at 2ba43f95c088 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Chris Rebert wrote: On Mon, Oct 12, 2009 at 4:27 AM, Piet van Oostrum p...@cs.uu.nl wrote: greg g...@cosc.canterbury.ac.nz (g) wrote: g MRAB wrote: And when someone says January 30, do they really mean the day before the last day of the month? g No, no, that's January -2, a *completely* different thing! But for someone else it would be February -2. And for still others, it's the last $DAYOFWEEK of the month, which just happened to fall on the 30th. That's a little more complicated: mx.DateTime.DateTime(2009, 1, 31).day_of_week 5 # which is a ... mx.DateTime.Weekday[mx.DateTime.DateTime(2009, 1, 31).day_of_week] 'Saturday' Now: # next month, last Saturday mx.DateTime.DateTime(2009, 1, 31) + mx.DateTime.RelativeDateTime(months=+1, day=1, weekday=(5, -1)) mx.DateTime.DateTime object for '2009-02-28 00:00:00.00' at 2ba43f93ebe0 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
On Fri, 09 Oct 2009 13:39:43 +0100, Tim Chase python.l...@tim.thechases.com wrote: Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ I'd hazard a guess that what we're actually seeing is people mentally rebasing their indices, i.e. counting from the end of the month rather than the start, which makes the last day of January and January 31 not the same thing really. Unfortunately we're very fuzzy about when we do things like this, which makes it hard on a poor programmer. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Rhodri James wrote: On Fri, 09 Oct 2009 13:39:43 +0100, Tim Chase python.l...@tim.thechases.com wrote: Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ I'd hazard a guess that what we're actually seeing is people mentally rebasing their indices, i.e. counting from the end of the month rather than the start, which makes the last day of January and January 31 not the same thing really. Unfortunately we're very fuzzy about when we do things like this, which makes it hard on a poor programmer. And when someone says January 30, do they really mean the day before the last day of the month? Where would it end? :-) -- http://mail.python.org/mailman/listinfo/python-list
mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
John Yeung wrote: On Oct 6, 4:10 pm, Stef Mientki stef.mien...@gmail.com wrote: thanks guys, mx works a bit better Another popular Python date library is dateutil: http://labix.org/python-dateutil It gives a certain amount of credit to mxDateTime (praising it but not being very clear how they are related; there is some mention of using the specification of mxDateTime). History goes a bit like this: mxDateTime was the first Python library to implement native date/time types for Python. I started the project in 1997. Back then I had a good look around at the various date/time libs and then decided to take a little more academic approach to the whole thing. The result was that you only need two basic types in mxDateTime: the DateTime object, which refers to a point in time, and the DateTimeDelta object, which allows measuring the time span between two such points. Note the absence of a Date object. These would be date/time range objects since they apply to the timespan of a full day with a time reference point at midnight. I decided to leave such ranges for a later stage in development - and have so far, never needed them :-) A bit later in 1998, I also added the RelativeDateTime object, which allows doing date/time calculations based on relative terms, e.g. x minus one year (which could mean 356 or 366 days depending on the year), first of next month (which could mean anything from 1-31 days), last of next month, Tuesday in 3 weeks, last Monday next month, etc. And again a bit later in 2000, I added the RelativeDateTimeDiff object which works a bit like an age function in that it tries to determine the RelativeDateTime value which has to be applied to a DateTime object in order to reach another one, say from your birthday to today. The result reads is more user- friendly than a bare DateTimeDelta, e.g. you get 40 years, 6 months, 3 days instead of 14796 days. In 2002 Zope Corp initiated the development of the datetime module, which borrowed a lot of design and API ideas from mxDateTime. However, it did not provide a date/time string parser and also misses out on lots of the other good stuff you can find in mxDateTime. Gustavo Niemeyer started to work on a date/time parser based on the datetime module - that's the python-dateutil library. He also added a relative date/time object which was one of the bits Zope Corp left out in the datetime module from mxDateTime and added some other things that are not currently part of mxDateTime: recurring events and time zones. mxDateTime continues to be actively developed - mostly driven by eGenix' own needs and experience we find in projects. Whenever we need something new, we can just add it to mxDateTime and since its release cycle is not bound to Python's, such enhancement are more readily available to others as well. Overall, my impression is that the datetime module was designed on the drawing board without actually touching real life usage scenarios. We've just done a project that used the datetime module for date/time related things instead of mxDateTime and found that while the implementation is similar to mxDateTime (naturally, see above), many useful features you find in mxDateTime are not available on the datetime objects. For future releases, we'll make the interaction between the two implementations more user friendly, e.g. it should be possible to pass a datetime object to mx.DateTime.DateTimeFrom() and call a method on DateTime objects to get a datetime module object with the same values. I would say mxDateTime and dateutil are the two heavyweights in this arena. As you would expect, they have a lot of overlapping functionality and which one is used is often just a matter of taste, or whichever one you happened to find first. One thing that dateutil provides that mxDateTime doesn't is support for lay person month operations. That is, as far as I can tell, mxDateTime tries not to dirty itself with the messy business of month arithmetic, whereas dateutil rolls up its sleeves and takes an honest stab at it. If you are writing a calendar/appointment application, or other end-user-facing program, I would expect dateutil to be a little more helpful. Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. mxDateTime does support month arithmetic via the RelativeDateTime object, but I'm not all that happy with the solution to the above problem. The alternatives are basically deciding between loosing data or raising an exception - both aren't really all that nice. Perhaps I'll just add a parameter to allow customization of the behavior depending on application needs. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...
Re: mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)
Month arithmetic is a bit of a mess, since it's not clear how to map e.g. Jan 31 + one month. Jan 31 + one month usually means add one to the month value and then keep backing off the day if you get an exception making the date, so you'd get Feb 31, exception, Feb 30, exception, Feb 29, possibly an exception, and possibly/finally Feb 28th. This makes pretty intuitive sense to most folks and is usually what's meant. I've found that issues and confusion stem more from the non-commutative reality that Jan 31 + (1 month) + (-1 month) != Jan 31 + (-1 month) + (1 month) or the non-associative Jan 31 + (1 month + 1 month) != (Jan 31 + 1 month) + 1 month :-/ So yes, messy it is! -tkc -- http://mail.python.org/mailman/listinfo/python-list
