allmydata.util.time_format.iso_utc_time_to_seconds() doesn't work in London if you ask it what the unix timestamp was in the 1970's #733

New Issue

zooko · 2009-06-11T03:03:10Z

zooko commented

2009-06-11 03:03:10 +00:00

(http://allmydata.org/buildbot/builders/Zandr%20Lenny-armel/builds/101/steps/test/logs/stdio)

I added some debug printouts:

time.mktime((1970, 1, 1, 0, 0, 1, 0, 1, 0)) == -3599.0

and

time.timezone == 0

That means that Zandr's linkstation says that the epoch began in its timezone one hour before it began in UTC, but also says that its timezone is the same as UTC. :-(

(http://allmydata.org/buildbot/builders/Zandr%20Lenny-armel/builds/101/steps/test/logs/stdio) I added some debug printouts: ``` time.mktime((1970, 1, 1, 0, 0, 1, 0, 1, 0)) == -3599.0 ``` and ``` time.timezone == 0 ``` That means that Zandr's linkstation says that the epoch began in its timezone one hour before it began in UTC, but also says that its timezone is the same as UTC. :-(

zooko added the

labels 2009-06-11 03:03:10 +00:00

zooko added this to the 1.5.0 milestone 2009-06-11 03:03:10 +00:00

zandr commented

2009-06-11 19:38:47 +00:00

Which is all correct for Europe/London
http://en.wikipedia.org/wiki/British_Summer_Time#Single.2FDouble_Summer_Time

Feel free to pick a more rational /etc/timezone, Americas/Los_Angeles is probably correct, but I could be talked into UTC

Which is all correct for Europe/London <http://en.wikipedia.org/wiki/British_Summer_Time#Single.2FDouble_Summer_Time> Feel free to pick a more rational /etc/timezone, Americas/Los_Angeles is probably correct, but I could be talked into UTC

tahoe-lafs added the

invalid

label 2009-06-11 19:38:47 +00:00

tahoe-lafs closed this issue

2009-06-11 19:38:47 +00:00

zooko commented

2009-06-11 22:09:09 +00:00

Changed the name of this ticket to reflect the fact that this function doesn't work in London, if you ask it what the unix timestamp was in the 1970's, and reopened the ticket. :-)

zooko removed the

invalid

label 2009-06-11 22:09:09 +00:00

zooko reopened this issue

2009-06-11 22:09:09 +00:00

zooko changed title from ~~time.mktime() wrong on Zandr's ARM box~~ to allmydata.util.time_format.iso_utc_time_to_seconds() doesn't work in London if you ask it what the unix timestamp was in the 1970's

2009-06-11 22:09:09 +00:00

zooko commented

2009-06-11 22:09:31 +00:00

Added a unit test of whether [time_format]source:src/allmydata/util/time_format.py's iso_utc_time_to_seconds() works in London, fixed it so that it does work in London. Fixed by changeset:8978cb073874b7d6.

Added a unit test of whether [time_format]source:src/allmydata/util/time_format.py's `iso_utc_time_to_seconds()` works in London, fixed it so that it does work in London. Fixed by changeset:8978cb073874b7d6.

zooko added the

fixed

label 2009-06-11 22:09:31 +00:00

zooko closed this issue

2009-06-11 22:09:31 +00:00

zooko commented

2009-06-13 03:02:41 +00:00

changeset:8978cb073874b7d6 doesn't work on Windows.

zooko removed the

fixed

label 2009-06-13 03:02:41 +00:00

zooko reopened this issue

2009-06-13 03:02:41 +00:00

zooko commented

2009-06-13 03:34:34 +00:00

Fixed again by changeset:45928315f6546185. changeset:45928315f6546185 is horrible. If you can make a simpler implementation that passes the unit tests, please go right ahead!

zooko added the

fixed

label 2009-06-13 03:34:34 +00:00

zooko closed this issue

2009-06-13 03:34:34 +00:00

zooko commented

2009-06-13 16:49:51 +00:00

Fixed in a clean way by changeset:cc2953e6632d6efb. Thanks, Black Dew! Opened http://bugs.python.org/issue6280 to complain about the fact that the function we were wishing for was always there in the Python Standard Library, but just in the wrong module.

Fixed in a clean way by changeset:cc2953e6632d6efb. Thanks, Black Dew! Opened <http://bugs.python.org/issue6280> to complain about the fact that the function we were wishing for was always there in the Python Standard Library, but just in the wrong module.

Sign in to join this conversation.