Re: master d0c77a1: Remove some assumptions about timestamp format

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

Michael Albinus wrote:

> Indeed. A NaN is not a time value all time functions do understand. For
> example,
> 
> (current-time-string 0.0e+NaN)
> => (error "Specified time is not representable")
> 
> I believe, a special string shall be returned here, like
> "Unspecified time" or so.

I'm afraid that sort of thing won't do in general. For example, what would 
format-time-string do? Or decode-time?

> Tramp will use such a constant anyway, it has taken '(0 0) until now. It
> will be returned by Tramp implementations of functions like
> `file-attributes' or `visited-file-modtime', and must be understood by
> the calling functions. `set-file-times', for example, does not
> understand this, and so do the functions in ls-lisp.el, and likely in
> Lisp packages in the wild.

If I understand you aright, you want a time value that will be treated as valid 
by standard time functions, and yet won't be a time value that any actual 
filesystem would return. In that case I suggest using the timestamp (0 0 0 1000) 
at the Lisp level. Although this is almost exactly the same time value that your 
Vinvalid_time code was using, it doesn't require special support at the C level.

Alternatively you could use (-1 65535 999999 999999), which is exactly the same 
value that your C code was effectively using. However, if it's run through 
struct timespec by the C code it will be floored to (-1 65535 999999 999000). 
Also, it can have problems on platforms where time_t is unsigned, which POSIX 
allows, and there are a few oddball systems that do that (QNX and VMS come to 
mind); although I don't know whether Emacs runs on these systems it'd be better 
not to exclude them arbitrarily. Another option would be (0 0 0 1), but I worry 
that this also would not survive an internal round trip through struct timespec.

All struct timespec-compatible timestamps are possible timestamps in the 
filesystem I use regularly (ext4). However, (0 0 0 1000) is so unlikely I don't 
think we need to worry about this, which is in contrast to the current Tramp 
usage of (0 0) which corresponds to timestamps that I have seen on real 
filesystems for various reasons.