DateTime UTC offset and UTC time wrong around DST switch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
egenix-mx-base (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
I ran through a weird problem with mx.DateTime
during last DST switch on CET on sunday 2012-10-28 01:00 UTC.
CET is on DST at UTC+2 up to 2012-10-28 01:00 UTC,
then switches to UTC+1.
In fact, for one hour past the switch, gmtoffset remained
stuck at +2 instead of +1, so gmtime was also bogus during that period.
The machine (x86, debian 4.0) monitors a timing system through the
use of a python script, and it needs TZ info. I ran through the problem
looking at the logs during the night of the switch from DST.
The logs are a bit verbose so I reproduce a simplified version
of what happenned on another machine ; this tiny script is run
on a Ubuntu 12.04.1, system time is UTC :
#!/usr/
from mx import DateTime
from time import sleep
t=DateTime.now()
while 1:
print "------
print "t = DateTime.now() : ", t
print "t.gmtoffset ", t.gmtoffset()
print "t.gmtime ", t.gmtime()
sleep(5)
I set time on the machine, run this script on CET timezone
and see what happens around the switch date (20121028 01:00 UTC).
1st test, reproducing the exact same behaviour that was observed on the
debian box :
I first set system time at 2012-10-27 23:59 UTC, and check :
root@ganymede:~# date -s"20121027 23:59"; date; TZ=CET date;
Sat Oct 27 23:59:00 UTC 2012
Sat Oct 27 23:59:00 UTC 2012
Sun Oct 28 01:59:00 CEST 2012
then I run the script, in CET timezone :
fm@ganymede:~$ TZ=CET ./test_tz.py
t = DateTime.now() : 2012-10-28 01:59:00.04
t.gmtoffset 02:00:00.00
t.gmtime 2012-10-27 23:59:00.04
All is ok. Two minutes later :
----
t = DateTime.now() : 2012-10-28 02:01:08.90
t.gmtoffset 02:00:00.00
t.gmtime 2012-10-28 00:01:08.90
still ok (but see ref [1] further in the text)
One hour later, one minute before the switch :
----
t = DateTime.now() : 2012-10-28 02:59:01.80
t.gmtoffset 02:00:00.00
t.gmtime 2012-10-28 00:59:01.80
Still ok
One minute later, after the switch :
----
t = DateTime.now() : 2012-10-28 02:00:01.86
t.gmtoffset 02:00:00.00
t.gmtime 2012-10-28 00:00:01.86
t is ok,
gmtoffset is bogus
gmtime is bogus, one hour back
that situation lasts one hour :
----
t = DateTime.now() : 2012-10-28 02:59:59.65
t.gmtoffset 02:00:00.00
t.gmtime 2012-10-28 00:59:59.65
still bogus.
----
t = DateTime.now() : 2012-10-28 03:00:04.66
t.gmtoffset 01:00:00.00
t.gmtime 2012-10-28 02:00:04.66
back to normal.
This is exactly the behaviour I observed in my logs.
2nd test : I first set the date 1 hour before the switch and check :
root@ganymede:~# date -s"20121028 00:00"; date; TZ=CET date
Sun Oct 28 00:00:00 UTC 2012
Sun Oct 28 00:00:04 UTC 2012
Sun Oct 28 02:00:12 CEST 2012
Then I run the script, after setting TZ :
fm@ganymede:~$ TZ=CET ./test_tz.py
t = DateTime.now() : 2012-10-28 02:01:31.54
t.gmtoffset 01:00:00.00
t.gmtime 2012-10-28 01:01:31.54
t is ok, but gmtoffset is bogus, and so is gmtime.
So at the same system (UTC) time 20121028 00:01, DateTime gives two different
answers (in one case, the script has been launched on UTC 20121027,
DateTime gives correct result ref [1]; if the script is launched on UTC 20121028 00:00,
DateTime gives bogus results for gmtime and gmtoffset.
This is not specific to CET, I tested with TZ=EST5DST :
----
t = DateTime.now() : 2012-11-04 01:59:59.25
t.gmtoffset -04:00:00.00
t.gmtime 2012-11-04 05:59:59.25
----
t = DateTime.now() : 2012-11-04 01:00:04.26
t.gmtoffset -04:00:00.00
t.gmtime 2012-11-04 05:00:04.26
bogus, gmtime jumped backward, gmtoffset is wrong.
----
t = DateTime.now() : 2012-11-04 01:00:09.26
t.gmtoffset -04:00:00.00
t.gmtime 2012-11-04 05:00:09.26
and one hour later :
----
t = DateTime.now() : 2012-11-04 01:59:58.81
t.gmtoffset -04:00:00.00
t.gmtime 2012-11-04 05:59:58.81
Stil bogus and finally :
----
t = DateTime.now() : 2012-11-04 02:00:03.81
t.gmtoffset -05:00:00.00
t.gmtime 2012-11-04 07:00:03.81
back to normal, gmtime jumping one hour forward.
(By the way, gmtime and gmtoffset should be named utctime
and utcoffset).
--
François Meyer Tel : (+33) 3 81 66 69 27 Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***fmeyer@venus:~$
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: python-
ProcVersionSign
Uname: Linux 3.2.0-31-generic x86_64
ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
Date: Wed Oct 31 20:00:15 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
TERM=xterm
PATH=(custom, user)
LANG=fr_FR.UTF-8
SHELL=/bin/bash
SourcePackage: egenix-mx-base
UpgradeStatus: No upgrade log present (probably fresh install)