Re: master d0c77a1: Remove some assumptions about timestamp format

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm afraid we need something better than that, as it mishandles NaNs. 
>> Also, there's no need for a special "invalid_time" value; you can just 
>> use a NaN.
>
> It's OK to support NaNs in time values, but I'm uneasy with the
> recommendation to use NaN as an invalid time.  IMO, NaNs should only
> come out of calculations, never from initial literal values of a
> program (except when the program wants to test NaN handling).

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.

> What is the problem with having a special invalid time value?

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.

(write-region "foo" nil "/tmp/foo")
(set-file-times "/tmp/foo" 0.0e+NaN)
=> (error "Specified time is not representable")

`set-file-times' shall simply return nil in this case, as said in the
docstring.

Therefore it would be better to a have an agreed constant, which is
understood by both Tramp and its callers.

What's wrong with the result of invalid_timespec() of systime.h, as
proposed earlier?

Best regards, Michael.