Caught out by daylight saving :-(

[Dave Angel]

That should work except for the few minutes before or after the 
daylight-savings-time change.  In other words between 1:55 and 2:01am on 
that particular date, twice a year.

During that time you still have to decide what you want to have happen, 
and then test your program to make sure it matches your expectations.  
Remember there's an hour in the fall whose corrected time is ambiguous, 
and there's a representation in the spring that is invalid (there are no 
valid times between 2 and 3 on that day).  Or you can just punt, and 
decide nobody's going to care during those times.

CinnamonDonkey wrote:
> It's not that fancy, but yes I am on windows.
>
> It's a script being called by Cruise Control .NET. They pass in a time
> stamp on the command line, "YYYYMMDD HH:MM:SS" and I need to advance
> it by 5 minutes before writing it back out to STDOUT to fake a source
> control modification.
>
> The process stopped working because it was always returning a time
> stamp -1 hr due to daylight saving.
>
> Changing utcfromtimestamp() to fromtimestamp() seems to have fixed
> it.
>
>
>
> On 30 Mar, 13:56, Dave Angel <da... at dejaviewphoto.com> wrote:
>   
>> There isn't any right answer.  There are two very different ways you can
>> interpret daylight savings time on a time conversion.  I suspect you're
>> on Windows, trying to look at an old file's datestamp, and expect it to
>> look like Windows displays it.  But Windows isn't even consistent with
>> itself, doing something different on a FAT system than on NTFS.
>>
>> For most of my own purposes, I've decided to only store the UTC times
>> for things.  Local time is useful only for interactive display.  And
>> that interactive display is calculated according to some context.
>>
>> To illustrate the problem, suppose you were in Chicago last month, and
>> modified a file at 2:00 pm, CST.   And now you are located in PDT time
>> zone, and want to know when the file was last modified.  Should you
>> convert the time zone and daylight savings, or should you convert only
>> time zone, or should you display the time as it was known to you at the
>> original change?
>>
>> And to make it more complex, suppose the disk drive involved was located
>> in France.  Just what time is correct?
>>
>> Anything other than UTC is subject to confusion.
>>
>> CinnamonDonkey wrote:
>>     
>>> Hi All,
>>>       
>>> I had the following bit of code which was working fine until we went
>>> into Daylight saving this weekend, now the result is an hour out.
>>>       
>>>     timeString =20090330 15:45:23"
>>>       
>>>     timeFormat =%Y-%m-%d %H:%M:%S'
>>>       
>>>     modificationTime =atetime.datetime.utcfromtimestamp( time.mktime
>>> ( time.strptime( timeString, timeFormat ) ) )
>>>     minutesToAdvance =atetime.timedelta( minutes=5 )
>>>       
>>>     modificationTime =odificationTime + minutesToAdvance
>>>       
>>>     datetimeString =tr ( modificationTime ).replace( ' ', 'T' )
>>>       
>>> The expected result should be:
>>>       
>>>     datetimeString =20090330T15:50:23"
>>>       
>>> But instead I get:
>>>       
>>>     datetimeString =20090330T14:50:23"
>>>       
>>> I believe it is going wrong at either the mktime() or utcfromtimestamp
>>> () stage.
>>>       
>>> What is the correct way to fix this compensating for daylight saving
>>> automatically?
>>>       
>>> Regards,
>>> SHaun >8)
>>>       
>>     
>
>
>