SEO

I was checking a date library and tested it against date.
There is one thing I found
date --date "19370701"
returns
Wed Jun 30 23:59:32 NST 1937

I have been checking 37331 dates
from date --date="19011216"
......
to date --date="20040229"
and only
date --date "19370701"
goes wrong.

I have checked with the coreutils maintainer of which date is part and
he couldn't reproduce it on his Debian machine

I have been pooking around and see that after a call to mktime (in
lib/getdate.c line 1302 coreutils 3.0.0 alpha) the tm structure is
filled in with data that I wouldn't expect.

I wonder is this specific for my machine. Not that it is a hugh problem
and I can live with it (How many times are you interested in 1937-07-01)
could someone see if it reproduce on his gentoo machine?

Thanks Rene

-----------------------software versions ----------------------------
I'm using
date --version
date (coreutils) 5.2.1

cat /proc/version
Linux version 2.4.28 (root@win2k) (gcc version 3.3.5 (Gentoo Linux
3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #17 Sun Mar 27 18:57:40 CEST 2005

/lib/libc.so.6
GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
pie-8.7.7.1).
Compiled on a Linux 2.4.22 system on 2005-03-16.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
The C stubs add-on version 2.1.2.
GNU Libidn by Simon Josefsson
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>

Rene wrote:

> I was checking a date library and tested it against date.
> There is one thing I found
> date --date "19370701"
> returns
> Wed Jun 30 23:59:32 NST 1937
>
> I have been checking 37331 dates
> from date --date="19011216"
> .....
> to date --date="20040229"
> and only
> date --date "19370701"
> goes wrong.
>
> I have checked with the coreutils maintainer of which date is part and
> he couldn't reproduce it on his Debian machine
>
> I have been pooking around and see that after a call to mktime (in
> lib/getdate.c line 1302 coreutils 3.0.0 alpha) the tm structure is
> filled in with data that I wouldn't expect.
>
> I wonder is this specific for my machine. Not that it is a hugh problem
> and I can live with it (How many times are you interested in 1937-07-01)
> could someone see if it reproduce on his gentoo machine?
>
> Thanks Rene
>
> -----------------------software versions ----------------------------
> I'm using
> date --version
> date (coreutils) 5.2.1
>
> cat /proc/version
> Linux version 2.4.28 (root@win2k) (gcc version 3.3.5 (Gentoo Linux
> 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #17 Sun Mar 27 18:57:40 CEST 2005
>
> /lib/libc.so.6
> GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al.
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
> pie-8.7.7.1).
> Compiled on a Linux 2.4.22 system on 2005-03-16.
> Available extensions:
> GNU libio by Per Bothner
> crypt add-on version 2.1 by Michael Glad and others
> linuxthreads-0.10 by Xavier Leroy
> The C stubs add-on version 2.1.2.
> GNU Libidn by Simon Josefsson
> BIND-8.2.3-T5B
> libthread_db work sponsored by Alpha Processor Inc
> NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> Thread-local storage support included.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/libc/bugs.html>

It is not reproducible at my computer:
-----
jt@tranholm jt $ date --date "19370701"
tor jul 1 00:00:00 CET 1937
jt@tranholm jt $ date --version
date (coreutils) 5.2.1
Written by David MacKenzie.

Copyright (C) 2004 Free Software Foundation, Inc.
Dette er frit programmel; se kildeteksten for betingelser for kopiering. Der
erINGEN
garanti; ikke engang for SALGBARHED eller EGNETHED FOR ET SPECIELT FORMÅL.
jt@tranholm jt $ cat /proc/version
Linux version 2.6.11-gentoo-r4 (root@tranholm) (GCC version 3.3.5 (Gentoo
Linux3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #1 Sat Mar 26 03:01:17 CET 2005
-----

Rene wrote:

> I was checking a date library and tested it against date.
> There is one thing I found
> date --date "19370701"
> returns
> Wed Jun 30 23:59:32 NST 1937

> I have been checking 37331 dates
> from date --date="19011216"
> .....
> to date --date="20040229"
> and only
> date --date "19370701"
> goes wrong.

Works here with /etc/localtime pointing to
/usr/share/zoneinfo/Europe/Berlin and an unset TZ variable. But:

# LC_ALL=C TZ=/usr/share/zoneinfo/Europe/Amsterdam date --date "19370701"
Wed Jun 30 23:59:32 NST 1937

I guessed your timezone from your mail address.

Time warp? Temporal discontinuity? Leap seconds?

Probably the time in the Netherlands was adjusted from one standard to
another standard in 1937.

Googling for "Europe/Amsterdam 1937" gives e.g.
<http://nssdcftp.gsfc.nasa.gov/usr/share/lib/zoneinfo/europe>,
which has:

# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/Amsterdam 0:19:28 - LMT 1892 May
0:19:28 Neth %s 1937 Jul
0:20 Neth %s 1940 May 16 0:40
1:00 M-Eur MET%s 1945 Apr 2 2:00
1:00 Neth MET%s 1977
1:00 EU MET%s

"man zic" tells a bit about the format of that file . The time zone
input files probably come with glibc and are compiled with zic to
produce the files in /usr/share/lib/zoneinfo.

Regards...
Michael

Rene enlightened us with:
> There is one thing I found
> date --date "19370701"
> returns
> Wed Jun 30 23:59:32 NST 1937

Same here, Europe/Amsterdam too.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?

same here, tz as Europe/Amsterdam gives wrong date. other tz's give
correct date (the one's i've checked that is)

wouter

Rene wrote:
> I was checking a date library and tested it against date.
> There is one thing I found
> date --date "19370701"
> returns
> Wed Jun 30 23:59:32 NST 1937
>
> I have been checking 37331 dates
> from date --date="19011216"
> .....
> to date --date="20040229"
> and only
> date --date "19370701"
> goes wrong.
>
> I have checked with the coreutils maintainer of which date is part and
> he couldn't reproduce it on his Debian machine
>
> I have been pooking around and see that after a call to mktime (in
> lib/getdate.c line 1302 coreutils 3.0.0 alpha) the tm structure is
> filled in with data that I wouldn't expect.
>
> I wonder is this specific for my machine. Not that it is a hugh problem
> and I can live with it (How many times are you interested in 1937-07-01)
> could someone see if it reproduce on his gentoo machine?
>
> Thanks Rene
>
> -----------------------software versions ----------------------------
> I'm using
> date --version
> date (coreutils) 5.2.1
>
> cat /proc/version
> Linux version 2.4.28 (root@win2k) (gcc version 3.3.5 (Gentoo Linux
> 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #17 Sun Mar 27 18:57:40 CEST 2005
>
> /lib/libc.so.6
> GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al.
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
> pie-8.7.7.1).
> Compiled on a Linux 2.4.22 system on 2005-03-16.
> Available extensions:
> GNU libio by Per Bothner
> crypt add-on version 2.1 by Michael Glad and others
> linuxthreads-0.10 by Xavier Leroy
> The C stubs add-on version 2.1.2.
> GNU Libidn by Simon Josefsson
> BIND-8.2.3-T5B
> libthread_db work sponsored by Alpha Processor Inc
> NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> Thread-local storage support included.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/libc/bugs.html>

In article <4258e188$0$15601$e4fe514c@dreader16.news.xs4all.n l>, wouter wrote:

>Rene wrote:
>> I was checking a date library and tested it against date.
>> There is one thing I found
>> date --date "19370701"
>> returns
>> Wed Jun 30 23:59:32 NST 1937

>same here, tz as Europe/Amsterdam gives wrong date. other tz's give
>correct date (the one's i've checked that is)

I suspect this is something with the timezone file. If you grep for 1937
in the europe file (this happens to be from tzdata2005g file from March
ftp://elsie.nci.nih.gov/pub/tzdata2005g.tar.gz), you'd find

# 0:19:32.13 AMT NST Amsterdam, Netherlands Summer (1835-1937)*
# 0:20 NET NEST Netherlands (1937-1940)*

and

# Howse's statement is only correct up to 1909. From 1909-05-01 (00:00:00
# Amsterdam mean time) onwards, the whole of the Netherlands (including
# the Dutch railways) was required by law to observe Amsterdam mean time
# (19 minutes 32.13 seconds ahead of GMT). This had already been the
# common practice (except for the railways) for many decades but it was
# not until 1909 when the Dutch government finally defined this by law.
# On 1937-07-01 this was changed to 20 minutes (exactly) ahead of GMT and
# was generally known as Dutch Time ("Nederlandse Tijd").

Apparently, the change took effect at 23:40:28 GMT 30 June 1937. I suspect
this might be where your strange time is coming from.

Old guy

man, are we Dutch crazy or what! i never knew about this. which is probably
a good thing otherwise i'd have emigrated already

Moe Trin wrote:
> I suspect this is something with the timezone file. If you grep for 1937
> in the europe file (this happens to be from tzdata2005g file from March
> ftp://elsie.nci.nih.gov/pub/tzdata2005g.tar.gz), you'd find
>
> # Howse's statement is only correct up to 1909. From 1909-05-01 (00:00:00
> # Amsterdam mean time) onwards, the whole of the Netherlands (including
> # the Dutch railways) was required by law to observe Amsterdam mean time
> # (19 minutes 32.13 seconds ahead of GMT). This had already been the
> # common practice (except for the railways) for many decades but it was
> # not until 1909 when the Dutch government finally defined this by law.
> # On 1937-07-01 this was changed to 20 minutes (exactly) ahead of GMT and
> # was generally known as Dutch Time ("Nederlandse Tijd").
>
> Apparently, the change took effect at 23:40:28 GMT 30 June 1937. I suspect
> this might be where your strange time is coming from.
>
> Old guy
>

In article <425aa8cc$0$179$e4fe514c@dreader5.news.xs4all.nl >, wouter wrote:

>man, are we Dutch crazy or what!

You really don't want me to try to answer that, do you? ;-)

>i never knew about this. which is probably a good thing otherwise i'd
>have emigrated already

The 19 minutes 32.13 seconds ahead of Greenwich translates to 4 degrees,
53 minutes 1.95 seconds of Longitude East, which puts it right around
Centraal Station in Amsterdam if my rather poor maps are to be believed.
The 20 minutes exactly, merely means exactly 5.000 degrees East which at
52 degrees 20 minutes North is about 7910 meters. And don't forget we're
talking about the Clarke 1866 spheroid, not the modern GPS coordinates.

At least your country is consistent. I'm in the state of Arizona, about
600 KM East of Los Angeles. Last Sunday morning, most of the USA went to
summer time - except for two states (Arizona and Indiana). In Arizona, we
don't do summer time, unless you are part of the Navajo Nation (the original
natives in 44000 square kilometers of the Northeast section of the state
who do use summer time), unless you are on the Hopi Indian Reservation (a
5250 square kilometer section right in the middle of the Navajo Nation)
because the Hopi don't use summer time, except for the 125 square kilometer
Najavo reservation at Jeddito within the Hopi Indian Reservation, where being
Navajo means they do use summer time... no, I'm not making this up.

The history of time can be very interesting, silly, and complex. The
several files that explain the timezones are worth a read when you have
time spare time to spend.

Old guy

Moe Trin wrote:
> In article <425aa8cc$0$179$e4fe514c@dreader5.news.xs4all.nl >, wouter wrote:
>
>
>>man, are we Dutch crazy or what!
> You really don't want me to try to answer that, do you? ;-)

i'd say everybody knows the answer to that anyway

> At least your country is consistent. I'm in the state of Arizona, about
> 600 KM East of Los Angeles. Last Sunday morning, most of the USA went to
> summer time - except for two states (Arizona and Indiana). In Arizona, we
> don't do summer time, unless you are part of the Navajo Nation (the original
> natives in 44000 square kilometers of the Northeast section of the state
> who do use summer time), unless you are on the Hopi Indian Reservation (a
> 5250 square kilometer section right in the middle of the Navajo Nation)
> because the Hopi don't use summer time, except for the 125 square kilometer
> Najavo reservation at Jeddito within the Hopi Indian Reservation, where being
> Navajo means they do use summer time... no, I'm not making this up.

omg! there wouldn't be a hopi reseveration within the jeddito reservation within
the hopi reservation within the navaho nation would there? <pant>

> The history of time can be very interesting, silly, and complex. The
> several files that explain the timezones are worth a read when you have
> time spare time to spend.

time is of the essence and has been an obsession of many in history.

this reminds me of a story i heard about a roadhouse along the south highway
through western australia. having no other settlements for a thousand kilometers
in either direction, they decided to create their own timezone 30 mins ahead
of Perth time, and 30 mins behind Adelaide time. just to make it easier

have you a source of other interesting time-facts maybe?

wouter

In article <42603006$0$158$e4fe514c@dreader12.news.xs4all.nl> , wouter wrote:

>omg! there wouldn't be a hopi reseveration within the jeddito reservation
>within the hopi reservation within the navaho nation would there? <pant>

Don't think so, but I'm sure the "local" cops have fun trying to figure
what time to put on the traffic tickets they write.

>time is of the essence and has been an obsession of many in history.

Why else do we have a complete news group just for the subject.

>this reminds me of a story i heard about a roadhouse along the south
>highway through western australia. having no other settlements for a
>thousand kilometers in either direction,

Nah, it just seems that bad.

> they decided to create their own timezone 30 mins ahead of Perth time, and
>30 mins behind Adelaide time. just to make it easier

Close. If you look in the 'australia' file that comes from nih.gov as part
of your timezone package, you will find this story, starting at about line
758. Look for the paragraph that has the word 'Madura' in it. Actually the
locals were pissed about the summer time as much as the two quite different
time offsets.

>have you a source of other interesting time-facts maybe?

See those zone files - there's all kinds of interesting stuff. I wasn't
actually aware of that story, but found it while looking at the file
trying to find the official time zone designations. The books that the
author uses look as if they have some interesting stuff too.

Old guy