Chile delay in 3 weeks the daylight time transition

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

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

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

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!

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

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

All packages copied to -updates.

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

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?

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.

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?

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

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.

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.

Exactly.

Thanks!

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 -

2008k versions uploaded to -proposed. Please test.

You mean 2008a instead 2008k ;-)

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

Thanks.

All copied to -updates.