need help with timezone conversion (unexpected side effect of time.mktime ??)

Paul Boddie paul at boddie.org.uk
Wed Jun 4 11:43:59 CEST 2008


On 3 Jun, 19:44, Ivan Velev <sir.hey... at gmail.com> wrote:
> > I've tried this with Python 2.3 and 2.4 on Red Hat Enterprise Linux 4
> > and can't reproduce the problem, even with other TZ values such as
>
> Thanks for the quick reply.
>
> Can you please let me know what value do you receive during your
> tests ?

With "Europe/Sofia" as the time zone, I get 1130634600.0 as the
result. I can't seem to find out what valid values of TZ should be
from the system documentation, but I did find this:

http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp/zoneinfo/src/theory

> As far as I can see, Python timezone API is just a wrapper around
> (shared ) native C libraries, but I really do not have any idea on how
> to reproduce this issue in a non-Python environment :(

A short C program behaves like Python in this regard:

#include <stdio.h>
#include <time.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
        char tzenv[] = "TZ=Europe/Sofia";
        struct tm time_str;
        time_t gmtStamp, problematicStamp;

        time_str.tm_year = 2005 - 1900;
        time_str.tm_mon = 10 - 1;
        time_str.tm_mday = 30;
        time_str.tm_hour = 3;
        time_str.tm_min = 10;
        time_str.tm_sec = 0;
        time_str.tm_wday = 6;
        time_str.tm_yday = 303;
        time_str.tm_isdst = -1;
        problematicStamp = mktime(&time_str);

        putenv(tzenv);
        tzset();
        time_str.tm_year = 2005 - 1900;
        time_str.tm_mon = 10 - 1;
        time_str.tm_mday = 30;
        time_str.tm_hour = 3;
        time_str.tm_min = 10;
        time_str.tm_sec = 0;
        time_str.tm_wday = 6;
        time_str.tm_yday = 303;
        time_str.tm_isdst = -1;
        gmtStamp = mktime(&time_str);
        printf("gmtStamp: %d\n", gmtStamp);
        return 0;
}

> btw. problem exists for this particular datetime only, an hour or more
> before / after that time givse identical results (this particular
> datetime is near the "daylight saving time change" moment)

The time functions have behaviour which can be very hard to explain
sometimes. I worked for a while on some patches in order to provide
more reasonable functions for common tasks, but it can be really
difficult to make reliable functions based on the POSIX API, and I'd
recommend the datetime module for any serious work with dates and
times.

Paul



More information about the Python-list mailing list