Chile delay in 3 weeks the daylight time transition

Bug #198129 reported by Germán Poo-Caamaño on 2008-03-03
14
Affects Status Importance Assigned to Milestone
tzdata (Ubuntu)
High
Martin Pitt
Dapper
Undecided
Martin Pitt
Edgy
Undecided
Unassigned
Feisty
Undecided
Unassigned
Gutsy
Undecided
Unassigned

Bug Description

The Chilean goverment has altered the dates when the Daylight time will
end this year.

Daylight time will end three weeks later this year. Instead of being held
by Saturday 8, it will be by Saturday 29.

The Chilean Official Time site with instructions is the following:
http://www.horaoficial.cl/cambio.htm (spanish).

This is also available at:
http://www.shoa.cl/noticias/2008/04hora/hora.htm

SHOA is the a Navy Agency in charge of the Official Time (the people who
also run horaoficial.cl).

It says:

   According to Supreme Decree No. 316 8 2008
   A. In the continent and Chilean Antarctic (America/Santiago)
      At 24:00 on Saturday, March 29, 2008. The time will be delayed in
   one hour, becoming 23:00 of the same day.
   B. In Easter Island and Isle Salas y Gomez (Pacific/Easter)
      At 22:00 on Saturday, March 29, 2008. The time will be delayed in
   one hour, becoming 21:00 the same day.

Regards,

Martin Pitt (pitti) on 2008-03-05
Changed in tzdata:
assignee: nobody → pitti
importance: Undecided → High
status: New → In Progress
Germán Poo-Caamaño (gpoo) wrote :

This problem has been solved in Debian (volatile). The patch must be fixed. I forgot to add the lines for 2009 and so on.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469194

Álvaro Herrera (alvherre-alvh) wrote :

The followup patch is also buggy. Please have a look at a comment from David Olson, maintainer of the TZ database: http://article.gmane.org/gmane.comp.time.tz/2094

Also it would probably be a good idea to post updates to PostgreSQL packages.

Hi,

Álvaro Herrera [2008-03-05 21:41 -0000]:
> The followup patch is also buggy. Please have a look at a comment from
> David Olson, maintainer of the TZ database:
> http://article.gmane.org/gmane.comp.time.tz/2094

Ah, thanks. If there's a new upstream version (2008a), I'm going to
use that onw.

> Also it would probably be a good idea to post updates to PostgreSQL
> packages.

Not necessary. We patched postgresql in all stable releases to use the
system tzdata now.

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

My 5 today: #198295 (hal), #191725 (hal), #181832 (jockey), #154214
(language-pack-ru), #193978 (gnome-control-center, jockey)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package tzdata - 2007k-1ubuntu4

---------------
tzdata (2007k-1ubuntu4) hardy; urgency=low

  * Add debian/patches/chile-dst2008.patch: Update DST rules for Chile to
    incorporate short-term DST change for 2008 (delayed for three weeks from
    March 08 to March 29). (LP: #198129)

 -- Martin Pitt <email address hidden> Thu, 06 Mar 2008 10:44:35 +0100

Changed in tzdata:
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

I uploaded updated packages to dapper, edgy, feisty, gutsy -proposed. Please test them for apparent regressions ASAP, I'd like to move them to -updates today or tomorrow. Thank you!

Changed in tzdata:
status: New → Fix Committed
status: New → Fix Committed
status: New → Fix Committed
Martin Pitt (pitti) wrote :

Oh, just for the record, the updated packages build and install fine for me, and Europe/Berlin timezone continues to work properly.

Changed in tzdata:
status: New → Fix Committed
Michael Vogt (mvo) wrote :

I verfied that for dapper installing the new locales package had the desired effect, the diff between
$ zdump Chile/Continnental
before and after shows the expected shift for dst from 9 Mar to 29 Mar.

I also verified that when installing tzdata the diff between zdmp zdump Chile/Continnental
shows the expected behavior:
 * edgy OK
 * feisty OK
 * gutsy OK

Martin Pitt (pitti) wrote :

All packages copied to -updates.

Changed in tzdata:
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released

Today, i surprised myself when i look the system clock changed. I configure the ntp.conf only with ntp.shoa.cl
I'm using Gutsy. I attached a copy of my ntp.conf
What's wrong?
Thanks

Martin Pitt (pitti) wrote :

Mauro,

details, please. Do you use the latest tzdata from gutsy-updates? Can you check whether the NTP server sends the wrong time perhaps, maybe try "sudo ntpdate ntp.ubuntu.com" and check whether the time is correct?

Germán Poo-Caamaño (gpoo) wrote :

I can confirm the bug.

I was expecting to have CLST this sunday 9, but it was CLT. The time was right, but not the timezone.

It didn't happen in Debian Etch. I checked them, and both of them (ubuntu and debian packages) shared the same patch.

I also checked with:
$ zdump -v 'America/Santiago' | grep 2008

According to this, the timezone should be CLST.

However, in Ubuntu was required to run dpkg-reconfigure tzdata.

At that moment, 'America' was not selected. I mean, there were no timezone selected.

After I choose 'America', pressing next I got 'Santiago' (Chile most common locations or so) selected. I pressed ok, and the timezone was fine again (CLST).

Also tried to repackage it using the latest tzdata 2008a (with the right patch for Chile), and it happened the same. It seems there is problem in other part.

Martin Pitt (pitti) wrote :

Hm, you already dpkg-reconfigure'd tzdata, so I guess the traces of the previous wrong state are lost (in particular, the contents of /etc/timezone and /etc/localtime). Do you still happen to have such an affected system? Did you happen to have upgraded this from Feisty?

Germán Poo-Caamaño (gpoo) wrote :

Fortunately, my wife also has a notebook in similar situation. It dosn't have the current tzdata package.

Both machines has been upgraded from Feisty.

$ cat /etc/timezone
User defined
~$ zdump /etc/localtime
/etc/localtime Mon Mar 10 20:26:41 2008 CLT

In my machine (after dpkg-reconfigure):

$ cat /etc/timezone
America/Santiago
$ zdump /etc/localtime
/etc/localtime Mon Mar 10 21:27:43 2008 CLST

I can test it tomorrow in another machine (installed with a pristine gutsy).

On Mon, Mar 10, 2008 at 9:29 PM, Germán Poo-Caamaño <email address hidden> wrote:
> Fortunately, my wife also has a notebook in similar situation. It dosn't
> have the current tzdata package.
>
> Both machines has been upgraded from Feisty.
> $ cat /etc/timezone
> User defined
> ~$ zdump /etc/localtime
> /etc/localtime Mon Mar 10 20:26:41 2008 CLT
>
> In my machine (after dpkg-reconfigure):
> $ cat /etc/timezone
> America/Santiago
> $ zdump /etc/localtime
> /etc/localtime Mon Mar 10 21:27:43 2008 CLST

It also happened here, a Gutsy install even after the updated tzdata.
I fixed on Sunday doing this:
- Clock->Adjust Date & Time
- Choose Timezone America/Santiago (The entry _was blank_)
- Click Synchronize now

Before the fix, the /etc/localtime was a normal file with some data.
After the fix, now is a simlink to
/usr/share/zoneinfo/America/Santiago
I didn't check the /etc/timezone file before the fix.

--
Aldrin Martoq

Germán Poo-Caamaño [2008-03-11 0:29 -0000]:
> Fortunately, my wife also has a notebook in similar situation. It dosn't
> have the current tzdata package.
>
> Both machines has been upgraded from Feisty.
>
> $ cat /etc/timezone
> User defined

Ah, that would be it. Unfortunately there were some problems on
Feisty->Gutsy upgrade (see bug #116193). On those machines it is
necessary to manually set a fixed time zone again.

Once you set it, it should behave correctly again; can you confirm
that?

Thank you, and sorry for that inconvenience!

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

My 5 today: #199471 (gnome-volume-manager), #136235 (gnome-volume-manager),
#193963 (sudo), #200089 (jockey), #199994 (b43-fwcutter)
    Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day

Germán Poo-Caamaño (gpoo) wrote :

I can confirm it's working again. I also test it using a pristine Gutsy.

But, yes, BUT...

tzdata-2007k with the currenct patch has a bug. It will change the time zone by Friday 28 night, instead of Saturday 29 night.

Do I need to reopen this bug? Sent a new patch? Report a new bug?

This time we have a 2 week's window more or less.

Martin Pitt (pitti) wrote :

We can reopen this for the SRU. So, in 2007k+patch there is

  Rule Chile 2008 only - Mar 29 3:00u 0 -

while 2008a has

  Rule Chile 2008 only - Mar 30 3:00u 0 -

Which seems to be correct according to you. So this is fixed in hardy, and we need 2008a in stables.

Changed in tzdata:
assignee: nobody → pitti
status: Fix Released → In Progress
status: Fix Released → In Progress
status: Fix Released → In Progress
status: Fix Released → In Progress
Germán Poo-Caamaño (gpoo) wrote :

Exactly.

Thanks!

Martin Pitt (pitti) wrote :

This is the effective diff between the latest patched 2007k and the new upstream 2008a:

-Rule Chile 2008 only - Mar 29 3:00u 0 -
+# N.B.: the end of March 29 in Chile is March 30 in Universal time,
+# which is used below in specifying the transition.
+Rule Chile 2008 only - Mar 30 3:00u 0 -

Martin Pitt (pitti) wrote :

2008k versions uploaded to -proposed. Please test.

Changed in tzdata:
status: In Progress → Fix Committed
status: In Progress → Fix Committed
status: In Progress → Fix Committed
status: In Progress → Fix Committed
Germán Poo-Caamaño (gpoo) wrote :

You mean 2008a instead 2008k ;-)

I just tested it and it works pretty fine in Gutsy.

Thanks.

Martin Pitt (pitti) wrote :

All copied to -updates.

Changed in tzdata:
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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