[Zope-dev] DateTime, strftime and TimeError

[Santi Camps]

En/na Andreas Jung ha escrit:

>
>
> --On Donnerstag, 12. Mai 2005 18:34 Uhr +0200 Santi Camps 
> <scamps at earcon.com> wrote:
>
>> En/na Andreas Jung ha escrit:
>>
>>>
>>>
>>> --On Mittwoch, 11. Mai 2005 16:08 Uhr +0200 Santi Camps
>>> <scamps at earcon.com> wrote:
>>>
>>>>
>>>>  >> d = DateTime('2045/30/01')
>>>>  >> d.strftime('%d/%m/%Y')
>>>> DateTime.DateTime.TimeError: The time 2369343600.000000 is beyond the
>>>> range of this Python implementation
>>>>
>>>> I've read that the reason was a validation to avoid int overflows.   I
>>>> think this could be fixed using datetime module (new in python 2.3)
>>>> instead of old time.localtime
>>>>
>>>
>>> After some testing: datetime has the same problems and it is unlikely
>>> that we can solve
>>> this problem in Zope as long as the underlying implementation in the
>>> libc sux (or better is
>>> constrained on 32 bit systems).
>>>
>>> -aj
>>
>>
>> At least is possible to fix the problem in strftime method.   I attach a
>> patch that works for me.   Hope this can be commited.
>>
>>
>
> If you provide some unittests then this would make a perfect patch :-)
>
> -aj
>
I'm trying to do it, but one test fails.  I can't understand this behaviour:

 >>> DateTime('2004/01/01')._tz
'GMT+1'
 >>> DateTime('2000/06/16')._tz
'GMT+2'

Why different time zones are assigned ?   I was thinking that the 
machine time zone was always used when not specified

Santi Camps