Bug#409784: marked as done (tzdata is wrong for epoch in Europe/London)
Your message dated Mon, 05 Feb 2007 15:19:51 +0100
with message-id <45C73D07.5040603@aurel32.net>
and subject line Bug#409784: tzdata is wrong for epoch in Europe/London
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: tzdata
Version: 2006p-1
localtime() resolves time==0 as Jan 1 1970 01:00 instead of 00:00 in
the Europe/London timezone. This was in etch; it also does this in
Debian sarge and gentoo, so I guess it's an old upstream bug.
It may be a bug in localtime() but certainly depends on the named
timezone (see below).
I'm amazed no one has spotted this before!
In fact, versions of libc/zoneinfo from 2000 (libc2.1.3) behave the same.
Is there something I'm missing here?
Repeat-by:
cat >> c.c << EOF
#include <time.h>
#include <stdio.h>
extern long timezone; /* Seconds west of gmt */
main()
{
time_t t = 0;
struct tm *tmp;
printf("Epoch in gmtime is %s", asctime(gmtime(&t)));
printf("Epoch in localtime is %s", asctime(tmp = localtime(&t)));
printf("timezone is %ld minutes east of UTC\n", -timezone/60);
printf("DST was%s in effect\n", tmp->tm_isdst ? "" : "n't");
}
EOF
$ cc c.c
$ TZ=Europe/London ./a,out # Europe/London is broken.
Epoch in gmtime is Thu Jan 1 00:00:00 1970
Epoch in localtime is Thu Jan 1 01:00:00 1970
timezone is 0 minutes east of UTC
DST wasn't in effect.
$ TZ=Europe/Paris ./a.out # Paris, on the same meridian, works ok.
Epoch in gmtime is Thu Jan 1 00:00:00 1970
Epoch in localtime is Thu Jan 1 00:00:00 1970
timezone is 0 minutes east of UTC
DST wasn't in effect
$ TZ=GMT+0 ./a.out # Absolute timezone works ok
Epoch in gmtime is Thu Jan 1 00:00:00 1970
Epoch in localtime is Thu Jan 1 00:00:00 1970
timezone is 0 minutes east of UTC
DST wasn't in effect
$ TZ=Europe/Warsaw # A location truly one hour out works ok
Epoch in gmtime is Thu Jan 1 00:00:00 1970
Epoch in localtime is Thu Jan 1 01:00:00 1970
timezone is 60 minutes east of UTC
DST wasn't in effect
Other named locations on the GMT+0 meridian may also be similarly broken.
M
--- End Message ---
--- Begin Message ---
Martin Guy a écrit :
> Package: tzdata
> Version: 2006p-1
>
> localtime() resolves time==0 as Jan 1 1970 01:00 instead of 00:00 in
> the Europe/London timezone. This was in etch; it also does this in
> Debian sarge and gentoo, so I guess it's an old upstream bug.
>
> It may be a bug in localtime() but certainly depends on the named
> timezone (see below).
>
> I'm amazed no one has spotted this before!
> In fact, versions of libc/zoneinfo from 2000 (libc2.1.3) behave the same.
> Is there something I'm missing here?
>
> Repeat-by:
> cat >> c.c << EOF
> #include <time.h>
> #include <stdio.h>
>
> extern long timezone; /* Seconds west of gmt */
>
> main()
> {
> time_t t = 0;
> struct tm *tmp;
>
> printf("Epoch in gmtime is %s", asctime(gmtime(&t)));
> printf("Epoch in localtime is %s", asctime(tmp = localtime(&t)));
> printf("timezone is %ld minutes east of UTC\n", -timezone/60);
> printf("DST was%s in effect\n", tmp->tm_isdst ? "" : "n't");
> }
> EOF
> $ cc c.c
> $ TZ=Europe/London ./a,out # Europe/London is broken.
> Epoch in gmtime is Thu Jan 1 00:00:00 1970
> Epoch in localtime is Thu Jan 1 01:00:00 1970
Between 1968 and 1971, the United Kingdom used the GMT+1 time all year.
See http://en.wikipedia.org/wiki/British_Summer_Time for the details.
The returned result is correct, I am therefore closing this bug.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
--- End Message ---
Reply to: