Re: dates before 1970

[Nick Dokos <nicholas.dokos@hp.com>]

Carsten Dominik <carsten.dominik@gmail.com> wrote:

> 
> On Mar 11, 2011, at 5:30 PM, Nick Dokos wrote:
> 
> > Carsten Dominik <carsten.dominik@gmail.com> wrote:
> > 
> > 
> >> THis is exactly the point, that it depends on how Emacs was compiled, and what kind of integer is used in the date representation.  Signed or unsigend, 32 or 64 bits (I think).
> >> 
> >> For example, Bastien can represent dates before 1970. I cannot.
> >> I can represent dates after 2038, Bastien cannot.
> >> 
> >> The work-around is to use diary sexps for dates before 1970, that seems to be safe.
> >> And then hope that by 2038, all computers will use 64 bit integers....
> >> 
> > 
> > But it's even more than that, no? Emacs's time implementation
> > (current-time, encode/decode etc) would have to change. In fact, this
> > might be the most significant limitation right now: the values they pass
> > around are (hi16 lo16 ms) so they assume that time values are 32 bits,
> > no matter what the underlying implementation says. I use 64-bit Linux on
> > an x86-64 laptop and my time_t is 64 bits (but I don't know if it's
> > signed or unsigned). Time for some experimentation I guess...
> 
> I believe that on your system you might get
> 
> (hi48 lo16 ms)
> 
> You can test if it is signed by trying a date before 1970
> 
>    (encode-time 0 0 0 1 1 1960)
> 

Ah, OK - thanks! I looked in current-time, saw the 0xffff mask and I
thought that the extra bits are truncated, but apparently not: I need to
go back and look at the C rules again.

I get

(encode-time 0 0 0 1 1 1960)
(-4816 20176)

(decode-time '(-4816 20176))
(0 0 0 1 1 1960 5 nil -18000)

so it is indeed signed.

I just pulled latest emacs and apparently Paul Eggert has been active in
making this code more robust, presumably after your conversations on the
emacs list.

Thanks,
Nick