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...@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)
--
http://mail.python.org/mailman/listinfo/python-list
