On Mar 14, 2011, at 4:11 PM, Nick Dokos wrote: > 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 have no idea what you are talking about :) > > 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. Great. Don't you love OpenSource projects? > > Thanks, > Nick > - Carsten
