DateTime UTC offset and UTC time wrong around DST switch

Bug #1073697 reported by François Meyer
6
This bug affects 1 person
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/bin/python
   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-egenix-mxdatetime 3.2.1-1ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-31.50-generic 3.2.28
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)

Revision history for this message
François Meyer (fmeyer-x) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.