Carsten Dominik <carsten.domi...@gmail.com> wrote: > > On Mar 11, 2011, at 5:30 PM, Nick Dokos wrote: > > > Carsten Dominik <carsten.domi...@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
