Re: Time not representable

[Paul Eggert <eggert@cs.ucla.edu>]

On 03/11/2011 05:01 AM, Carsten Dominik wrote:
> Why is it that these things are different on different systems?  Is
> this under the control of Emacs, or does this depend on system
> libraries which are being used?

Both.

Time stamps on most modern systems have nanosecond resolution,
but Emacs's internal time stamps only use microsecond resolution.
This means (for example) that Emacs cannot determine that
one file is newer than another, even when it is newer.
This bug really should get fixed at some point.

In addition to resolution problems, there are also the
range problems that you alluded to.  time_t is usually
a signed 32-bit or 64-bit integer; a few systems use unsigned
integers, and several use signed integers but do not allow
negative values.  (Emacs in theory could use 32-bit EMACS_INT
internally on a system with 64-bit time_t, but I expect that
combination is rare.)

You have to be careful about inferring ranges from behavior,
though, because when Emacs converts times, it sometimes doesn't check
for overflow.  This means you can get undefined behavior if you use
time stamps that cannot be represented internally.
For example, (encode-time 0 0 0 1 1 1152921504606846976)
returns the obviously-bogus value (-948597 62170)
on my RHEL 5.5 x86-64 host, whereas it correctly reports
a "Specified time is not representable" error on
my Ubuntu 10.10 x86 host.  This is a bug that should get
fixed at some point too, though I expect it's less important
in practice than the nanosecond-resolution bug.