> One of them is new to me and I've ticketed it: #735. The other ones > look like we can't call Python's time.mktime(), passing the beginning > of January 1, 1970 as the argument, on your Windows machine.
I think i've figured this one - python docs of mktime say "The earliest date for which it can generate a time is platform-dependent." while the C library mktime() on windows "If timeptr references a date before midnight, January 1, 1970, or if the calendar time cannot be represented, _mktime32 returns –1 cast to type time_t" (see http://msdn.microsoft.com/en-us/library/d1y53h2a(VS.80).aspx ). Because my clock is UTC+2, midnight 1970-1-1 here is actually 22:00:00 1969-12-31 UTC and mktime() doesn't like that. >>> time.mktime((1970,1,1,2,0,0,0,1,0)) # 2:00:00 1970-1-1 UTC+2 = midnight utc >>> = start of epoch 0.0 >>> time.mktime((1970,1,1,1,59,59,0,1,0)) # one second earlier Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: mktime argument out of range > Interesting, we can on our Windows buildslave. Maybe this is actually > an effect of the library juggling you had to do with regard to the > symbol for "time()". I don't think that anything done while linking an extension can affect what python own functions bind to. Note that i did not change any actual DLL, only the export libs which tell the linker where stuff can be found. What timezone is your buildslave in? This test should probably pass if it's in UTC or UTC-x. > Hm, #735 says that > the answer your system computes for "How many seconds after the epoch > was the first second of 2009-03-18 UTC?" is 7200 seconds less than the > right answer. Strange! If i follow the test correctly, this is what is happening: p=parse_date which calls iso_utc_time_to_seconds, then.... origtz = os.environ.get('TZ') os.environ['TZ'] = "UTC" # <=== I don't think windows knows about the TZ variable, this is a Unix or GNU thing if hasattr(time, 'tzset'): # <=== And windows python doesn't have time.tzset() either time.tzset() try: return time.mktime( (year, month, day, hour, minute, second, 0, 1, 0) ) + subsecfloat # <=== so this uses local timezone The offset between expected and actual results is 7200 (=2 hours) which is my offset from UTC. This also seems to be happening on your windows buildbot http://allmydata.org/buildbot/builders/windows/builds/1482/steps/test/logs/stdio I think this would better be done by adding time.timezone (offset from utc in seconds) to the result or just using http://docs.python.org/library/calendar.html#calendar.timegm instead of trying to modify the local timezone. > Yes please! Any or all of those would be great! I've got buildbot installed on the windows system an need the user/password/connection info to setup it. The debian-unstable system will be ready when i get some spare time to update it, hopefully tomorrow. _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
