RE: zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800)
While standard time wasn't introduced before 1800 anywhere, there are earlier time oddities (such as swiches from the Julian to the Gregorian calendar, switches to the Julian calendar, skipping of the year zero, and leap year gyrations). While the current time zone package doesn't try to handle these oddities, other packages might. Since zdump is supposed to be independent of the rest of the time zone package, the built-in limits of -500 and 2500 are designed to run from earliest at-all-likely-to-be-reflected oddity to the present day (with a couple of hundred years of slop at either end). It's always possible, of course, to... zdump -v -c1800,2500 US/Pacific ...to get the desired effect. --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Thursday, February 23, 2006 12:39 PM To: tz@lecserver.nci.nih.gov Subject: zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800) The command "zdump -v US/Pacific" took 36 CPU seconds on my (admittedly aging) 440 MHz UltraSPARC-IIi machine. There are no doubt other speedups that could be done, but the following obvious one shrank the CPU time to 20 CPU seconds. Standard time wasn't introduced before 1800 anywhere that I know of. --- zdump.8 2006/02/20 15:08:17 2006.2 +++ zdump.8 2006/02/23 17:29:26 2006.2.0.1 @@ -41,7 +41,7 @@ otherwise. .BI "\-c " [loyear,]hiyear Cut off verbose output near the start of the given year(s). By default, -the program cuts off verbose output near the starts of the years -500 and 2500. +the program cuts off verbose output near the starts of the years 1800 and 2500. .SH LIMITATIONS The .B \-v --- zdump.c 2006/02/21 21:07:30 2006.2.0.1 +++ zdump.c 2006/02/23 17:29:26 2006.2.0.2 @@ -18,7 +18,7 @@ static char elsieid[] = "@(#)zdump.c 8.1 #endif /* !defined isascii */ #ifndef ZDUMP_LO_YEAR -#define ZDUMP_LO_YEAR (-500) +#define ZDUMP_LO_YEAR 1800 #endif /* !defined ZDUMP_LO_YEAR */ #ifndef ZDUMP_HI_YEAR
"Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov> writes:
While standard time wasn't introduced before 1800 anywhere, there are earlier time oddities (such as swiches from the Julian to the Gregorian calendar, switches to the Julian calendar, skipping of the year zero, and leap year gyrations). While the current time zone package doesn't try to handle these oddities, other packages might.
I don't know of any such package, but even if there were such a thing, zdump wouldn't work with it. For example, it would get hopelessly confused (loop or crash or report wrong data, I don't know what) if given an implementation that accurately implemented the calendar used in the English colonies in America before 1750, where the year began on March 25. Or the Byzantine calendar, where the year began on September 1. Or the Japanese calendar, where the year numbers restart at 1 every time there is a new emperor. One other data point: in all of these other systems, leap years are not even a multiple of 4, much less the 4/100/400 Gregorian rule that zdump assumes. There's no real need to go back before 1800 (and expose all those zdump "bugs" :-), until and unless we change zdump to support calendars other than the proleptic Gregorian calendar ("proleptic" because it assumes the Gregorian calendar is valid for all time). On the other hand, I can think of four transitions that I would like zdump to report, for 64-bit hosts. These transitions will test bugs in the implementation of the proleptic Gregorian calendar. First is the transition between localtime returning NULL (because time_t is too negative) and localtime working (because time_t is barely in range). Similarly for the maximum time_t that localtime works on. And two more transitions for gmtime. These boundaries should be findable fairly easily, and if you're interested I can try to find some time to write up the code.
Paul Eggert said:
For example, it would get hopelessly confused (loop or crash or report wrong data, I don't know what) if given an implementation that accurately implemented the calendar used in the English colonies in America before 1750, where the year began on March 25.
Nitpick - the last year starting on March 25th in England was 1751 (which was therefore only 287 days long, much less than the 355 days of 1752).
One other data point: in all of these other systems, leap years are not even a multiple of 4,
Right: the leap day previous to 1752-02-29 was 1747-02-29, 24 days before the end of 1747. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
participants (3)
-
Clive D.W. Feather -
Olson, Arthur David (NIH/NCI) [E] -
Paul Eggert