Time, Time Zone and the total mess...

07 05 2009
So, I realized that in my toy app all times where off by two hours. I thought »Ha, that's easy.« and now I'm officially surrendering.

I created a quite simple testcase, and even that one tries to tell me that these times are the same:

2009-05-07 12:00:00 +0000
2009-05-07 13:00:00 +0200


So, until now I thought "+0200" means »two hours ahead of UTC«. Why is it supposed to be one nowadays?

So now my questions: Is this Ubuntu Hardy, I'm using here, a total mess? Do I do something wrong? Doesn't this work at all? Why does it keep trying to pretend that these times are the same?


Trackbacks


01 11 2009
Time, Time Zone and the total mess… (continued)
This blog post is intended to be a reply containing the information that I would have needed abut half a year ago: as Jürg has correctly pointed out: gmtime() would have helped me a lot (but isn't portable) as I realized during the last week, replac
Weblog: herzi.eu
Tracked: Nov 01, 11:16

Comments

Display comments as (Linear | Threaded)
07 05 2009
#1 Jürg Billeter (Reply)

Jürg Billetermktime operates on local time and you're feeding it UTC. This yields very strange results due to DST corrections... Use timegm instead of mktime to convert a struct tm to a time_t.
15 05 2009
#1.1 Sven Herzberg (Reply)

Sven HerzbergThanks for this tip. timegm() was indeed exactly what I was looking for…
07 05 2009
#2 Chris Lord (Reply)

Chris LordUse libjana (in gnome git as 'jana': http://git.gnome.org/cgit/jana/) and forget all these worries about timezone handling being difficult and full of edge-cases :-)
07 05 2009
#3 Dave Barry (Reply)

Dave BarryFrom the manpage for mktime(3) on my ubuntu jaunty system:

Calling mktime() also sets the external variable tzname with information about the current timezone.

If you insert the mktime(&time) call before your first call to strftime(), this case yields the expected result.
11 05 2009
#4 JM Ibanez (Reply)

JM IbanezIt's most likely a DST issue. London (UTC) would probably be in DST, yielding the time 1200, for the non-DST time 1100 -- which corresponds with 1300 at UTC+2 (without DST, most likely).
14 05 2009
#4.1 Anonymous (Reply)

Does not look like DST problem. I tried it too here and changing the date to 2009-03-07 (which is before DST) results in:

2009-03-07 12:00:00 +0000
2009-03-07 12:00:00 +0100
14 05 2009
#5 Sebastian Rittau (Reply)

Sebastian RittauIt is indeed a DST problem. If you print the time.tm_isdst field before and after the call to mktime, you will see that before the field is set to 0 and after it is set to 1. So basically mktime is trying to make sense of that.

Add Comment


Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA




Submitted comments will be subject to moderation before being displayed.