bug#55635: `make-decoded-time' incorrectly sets DST to nil, it should be -1 (guess)

[Paul Eggert]

On 5/28/22 09:53, Eli Zaretskii wrote:
> this situation already exists with time units anyway.  You can add
> an hour to some other time, but there's also a valid time stamp that
> expresses 1 hour past the epoch UTC, and their values are exactly
> identical.

Quite true for encoded times that count seconds. However, Max also has a 
point that decoded timestamps like (19 17 10 28 5 2022 6 t -25200) are 
problematic as relative times. Although their first six elements can be 
treated as either relative or absolute, their last three elements don't 
make much sense in relative times.

The recent change in the master branch that lets encode-time take 
six-element lists suggests that perhaps a better way to represent a 
relative decoded time would be as a 6-element list.

With that in mind, here are three suggestions.

1. decoded-time-dst should return -1, instead of nil, when given a 
6-element list, since nil means standard time and -1 means DST is unknown.

2. make-decoded-time should generate a six-element list unless given a 
DST or ZONE arg.

3. Document the above nicely. (This is the hardest part....)