[egenix-users] Parsing ARPA dates before Unix epoch breaks?

[Ramon Felciano]

(RESEND: Sorry, meant to CC the list on this as well...)

Hi Marc --

Thanks for the quick reply. Is there a way I can re-construct the
original date (with time offset) such that it will be formatted
correctly by the mxTimeDate str() function? I'm not actually calling
gmtoffset() myself, but that's where the str function seems to choke:

>>> from mx.DateTime.ARPA import *
>>> s = "Wed, 1 Jan 1969 00:43:25 -0400"
>>> delta = ParseDateTime(s) - ParseDateTimeUTC(s)
>>> delta
<mx.DateTime.DateTimeDelta object for '-04:00:00.00' at 1363840>
>>> ParseDateTime(s) + delta
<mx.DateTime.DateTime object for '1968-12-31 20:43:25.00' at 1369be0>
>>> str(ParseDateTime(s) + delta)
Traceback (most recent call last):
 File "<interactive input>", line 1, in <module>
 File "C:\Python26\lib\site-packages\mx\DateTime\ARPA.py", line 170, in str
   tz = datetime.gmtoffset()
Error: cannot convert value to a time value
>>>

Thanks,

Ramon

> On Thu, Apr 15, 2010 at 4:07 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Ramon Felciano wrote:
>>> Hi --
>>>
>>> I've run into trouble parsing dates using the ARPA module in
>>> mxDateTime on Windows. It appears that it is based on a limitation
>>> around dates before the Unix epoch, which I thought this package
>>> helped you work around:
>>>
>>>>>> mx.__version__
>>> '3.1.2'
>>>>>> mx.DateTime.ARPA.ParseDateTimeUTC("Thu, 1 Jan 1970 00:43:25 -0400").gmtoffset()
>>> <mx.DateTime.DateTimeDelta object for '-08:00:00.00' at 1497b60>
>>>>>> mx.DateTime.ARPA.ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400").gmtoffset()
>>> Traceback (most recent call last):
>>>   File "<interactive input>", line 1, in <module>
>>> Error: cannot convert value to a time value
>>>
>>> Is this expected behavior?
>>
>> Yes, since the .gmtoffset() method uses the C lib's time function
>> in order to calculate the offset of the object's date/time
>> to GMT/UTC, provided that the object uses local time.
>>
>> On some systems, this fails for dates prior to the epoch and there's
>> nothing much we can do about it.
>>
>> On others it works just fine, e.g. Linux:
>>
>>>>> ParseDateTime("Wed, 1 Jan 1969 00:43:25").gmtoffset()
>> <mx.DateTime.DateTimeDelta object for '01:00:00.00' at 2b46aebfac70>
>>>>> ParseDateTime("Wed, 1 Jan 1960 00:43:25").gmtoffset()
>> <mx.DateTime.DateTimeDelta object for '01:00:00.00' at 2b46aec16b58>
>>>>> ParseDateTime("Wed, 1 Jan 1920 00:43:25").gmtoffset()
>> <mx.DateTime.DateTimeDelta object for '01:00:00.00' at 2b46aebfac70>
>>>>> ParseDateTime("Wed, 1 Jan 1910 00:43:25").gmtoffset()
>> <mx.DateTime.DateTimeDelta object for '01:00:00.00' at 2b46aec16b58>
>>>>> ParseDateTime("Wed, 1 Jan 1810 00:43:25").gmtoffset()
>> <mx.DateTime.DateTimeDelta object for '00:53:28.00' at 2b46aebfac70>
>>>>> ParseDateTime("Wed, 1 Jan 1710 00:43:25").gmtoffset()
>> <mx.DateTime.DateTimeDelta object for '00:53:28.00' at 2b46aec16b58>
>>
>> Also note that ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400")
>> will return a DateTime instance pointing to UTC time, ie. the
>> .gmtoffset() is not applicable.
>>
>> You can use ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") to
>> get the date/time parsed without the timezone part and then
>> take the difference to extract the already provided timezone
>> information:
>>
>>>>> from mx.DateTime.ARPA import *
>>>>> offset = ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") - ParseDateTimeUTC("Wed, 1 Jan 1969
>> 00:43:25 -0400")
>>>>> offset
>> <mx.DateTime.DateTimeDelta object for '-04:00:00.00' at 2b46aec163b0>
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Source  (#1, Apr 16 2010)
>>>>> 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/
>>
>