Re: Time64 needs to call VMS.C gmtime() and localtime() always.

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:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser