[tahoe-dev] Windwos installation problems

[Black Dew]

> 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.