Guido van Rossum wrote:
Now when we want to translate from UTC to local time, we have to recover the parameters of g() by interpreting f()!
(There's more, but I don't want to spend all day writing this.)
That was a great ASCII art graph, though. It made me smile. :-)
Maybe this is what Marc-Andre was hinting at: apparently mxDateTime knows how to access the C library's timezone tables.
I was working on a possible solution when I stumbled across the fact that the current tzinfo documentation doesn't seem to specify whether the dst() method expects the "dt" argument to be in terms of UTC or local time. Sometimes when working on the problem I assumed dt was in UTC, making the conversion from UTC to local time easy, and at other times I assumed dt was in local time, making the conversion from local time to UTC easy. Which is it? Once that's decided, it seems like the "hard" case (whichever is the hard one) could be solved by first computing the UTC offset at the time requested, then computing the UTC offset at a time adjusted by the offset. If the two computed offsets are different, you know you've straddled a daylight savings boundary, and maybe the second offset is the correct offset. That's just a guess. feebly-trying-to-catch-up-to-tims-genius-ly y'rs, Shane