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. 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. So doubles are perfectly good for this job. Nicholas Clark * http://en.wikipedia.org/wiki/Tidal_acceleration
