DateTime UTC offset and UTC time wrong around DST switch

Bug #1073697 reported by François Meyer on 2012-10-31
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
egenix-mx-base (Ubuntu)
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)

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

Other bug subscribers