On Feb 22, 2009, at 5:00 AM, Nicholas Clark wrote:
On Sat, Feb 21, 2009 at 04:00:28PM -0600, Craig A. Berry wrote:
On Feb 19, 2009, at 8:55 AM, John Malmberg wrote:
Malmberg wrote:
Thomas Pfau wrote:
Current definition from Compaq C V6.4-005 on OpenVMS VAX V7.3:
typedef unsigned long int __time_t;
So VMS Perl should be good to 2106 if just use the wrapper routines
in VMS.C.
That's better than failing in 2038, but if you were doing
calculations
for a 99-year lease you'd already be in trouble today. The time64
code takes things to a somewhat silly extreme by insisting on using a
64-bit integer for year as well as for time_t, thus moving the year
limit beyond the 2 billion point. I have no idea what the practical
application of that is, but there are advantages to extending the
range by centuries rather than decades.
Date & Time calculations beyond the range of 2**53 seconds are
meaningless.
And if we needed more, the VAX D_FLOAT double format has a 56-bit
mantissa instead of the 53 bits of the IEEE double :-).
The actual useful range is way less than that:
First, consider times backwards. Daylight saving time has been
around for
less than 0x80000000 seconds before 1970, and the introduction was not
clean cut. It seems that in the UK it was first introduced in 1916
as an
aggregate 80 minute clock shift, done in 4 parts:
http://www.webexhibits.org/daylightsaving/c.html
yet the timezone database on this 64 bit machine doesn't seem to
agree:
$ ./perl -le 'print scalar localtime -1690000000'
Mon Jun 12 20:33:20 1916
$ ./perl -le 'print scalar gmtime -1690000000'
Mon Jun 12 19:33:20 1916
thinking that it's only an hour. Which, it seems, is because the
timezone
database is buggy:
$ ./perl -le 'print scalar gmtime -1810000000'
Fri Aug 23 22:13:20 1912
$ ./perl -le 'print scalar localtime -1810000000'
Fri Aug 23 23:13:20 1912
Willet died in 1915, and his idea was not introduced in his
lifetime. So
historical timezone data is bogus, and we're already into garbage
in, garbage
out. Summertime data stops being of use.
Go back a centaury further, and clocks weren't even synchronised
within the
countries we now treat as consistent timezones. Bristol time was 12
minutes
behind London time, because noon was determined (locally) by the sun
being
overhead. [And no, I'm not sure whether that was at a particular
time of year,
or whether the clocks tracked the difference across the year between
solar
time and mean time: http://en.wikipedia.org/wiki/Equation_of_time
]. It was only the coming of the railways that standardised time
across the
country. So conversion of an epoch time to a time string with any
resolution
better than an hour stops being of use.
Go back a centaury further:
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
So, the UK and its dominions adopted the Gregorian calendar, 200
years after
the Roman Catholic world. So, I'd expect this to differ:
$ LC_ALL=it_IT cal 9 1752
Settembre 1752
Do Lu Ma Me Gi Ve Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Eh? What's up? What's up is that we don't even have data on when a
given
"timezone" swapped calendars. So we can't even usefully say what day
of the
week it is.
Now, consider times forwards.
$ TZ=GMT perl -le 'print scalar localtime 2**53'
Mon Nov 12 07:36:32 285428751
$ TZ=US/Pacific perl -le 'print scalar localtime 2**53'
Sun Nov 11 23:36:32 285428751
What's the world going to be like 285 million years from now?
Well, it's not clear that it's going to be a Sunday night/Monday
morning.
The Earth's rotation is slowing. Wikipedia suggests that a day was
21.9±4 hours 620 million years ago*, and whilst the slowdown is not
actually
linear, a linear first stab would put the day as being 25 hours
long. So
any day information we calculate is useless.
It's not even clear that it's going to be the right timezone any
more. Iceland
is currently spreading at (IIRC) 20mm/year, so if that continues for
285
million years, Iceland would be 5700km wider, and hence the Pacific
coast
of the US would be (roughly) 5700km further from Greenwich, about 3
timezones
further. So localtime is completely bogus by then too.
So, really, there's not very much that useful we can say about 2**53
seconds
after 1970, apart from the fact that it's roughly 285422900AD, which
we could
do without needing a computer, let alone a timezone database.
Thanks for chasing down all the details. It had occurred to me that
time zones and calendars were rather puny models to throw up against
geological and cosmological time calculations, but I had no idea we
were headed for 25-hour days and an Icelandic invasion :-).
So doubles are perfectly good for this job.
for time_t, yes. For tm->tm_year, 32-bit (or even 16-bit) integers
seem more than adequate for years that are worth talking about in
calendar time.
I may have a crack at doing that to the time64.c code for a slight
gain in portability, but I don't see that as a blocker for anything
important. I have no idea whether any of this is a candidate for
5.10.1, but I believe even now (after recent patches) there is already
benefit for real (as well as absurd) cases on platforms that have
Quad_t, and for platforms that don't, they are no worse off than they
were.
Nicholas Clark
* http://en.wikipedia.org/wiki/Tidal_acceleration
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
