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

[Maxim Nikulin <m.a.nikulin@gmail.com>]

Consider the following example:

     (format-time-string
      "%F %T %Z %z"
      (encode-time
       (make-decoded-time :year 2022 :month 3 :day 31
     			 :hour 23 :minute 30 :second 0
     			 :zone "Europe/Madrid"))
      "Europe/Madrid")
     "2022-04-01 00:30:00 CEST +0200"

I believe that the result should be
     "2022-03-31 23:30:00 CEST +0200"
It can be obtained if :dst -1 is explicitly added to the 
`make-decoded-time' arguments.

Since `make-decoded-time' is defined using `cl-defun', I think, it is 
better to use -1 ("guess") default value for the :dst argument, not nil 
that explicitly says "no daylight saving time".

There is `decoded-time-set-defaults', but it does not help

     (format-time-string
      "%F %T %Z %z"
      (encode-time
       (decoded-time-set-defaults
        (make-decoded-time :year 2022 :month 3 :day 31
			  :hour 23 :minute 30)
        "Europe/Madrid"))
      "Europe/Madrid")
     "2022-04-01 01:30:00 CEST +0200"

This case I have no idea how to fix the issue.

An example in the `decoded-time-add' docstring
 >   (decoded-time-add (decode-time) (make-decoded-time :month 2))
adds even more confusion. If `make-decoded-time' is intended for 
intervals, not timestamps than it should not have DST and TZ values at 
all. Time interval may be added to timestamp, and time zone and daylight 
saving time flag is the property of particular timestamp while the same 
interval may be added to various timestamps and the actual result 
depends on the base timestamp.

Timestamp and interval are different types and should not be used 
interchangeably. nil/t/-1 interpretation difference for DST causes 
issues like (bug#54731), so it should be handled with care.