Re: Questions about encode-time and decode-time

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Thu, 25 Mar 2021 08:51:03 +0100
> 
> Hi Elli, Thank you for the time spent answering me. I must admit that
> I don't know much about timezones. I simply tried to understand what
> was happening following a time error in the decoding of a Icalendar
> appointment. According to what I understand the data of the VTIMEZONE
> block is decoded into a string of the type
> "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00" and associated
> with the TZID. Then this string is used in encode-time operations.

This has no chance of working correctly on Windows around the DST
change date.  We need some code to convert these DST specifications to
what Windows can understand; patches welcome.

> As you told me those strings weren't handled properly on Windows, I
> tested with a simple ID. Now I know I should have used CET but I am
> suprised by the result of:
> 
> (decode-time (encode-time (list 0 30 9 14 3 2021 nil -1 "CET")))
> --> (0 30 10 14 3 2021 0 nil 3600)
> 
> I thought I would get (0 30 9 14 3 2021 0 nil 3600).  To get that
> value I have to call:
> 
> (decode-time (encode-time (list 0 30 9 14 3 2021 nil -1 "CET")) "CET")
> 
> The docstring says: The optional ZONE is omitted or nil for Emacs
> local time, ... So what is the Emacs local time? 

Whatever DST information is stored on your Windows system -- the same
information that Windows itself uses to automatically switch from
Standard time to Daylight Savings time.

The problem here is the difference between the rules Windows uses
natively to switch into and from DST, and the rules the C runtime
library uses when TZ is set to the likes of "CET".  The former is
generally quite accurate and follows the rules used by Posix systems,
but the relevant Windows APIs don't support the Posix-style DST string
rules such as "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00".
The latter, also known as "USA rules for DST", assume that DST is
entered on 02:00 on the first Sunday in April and exited on 01:00 of
the last Sunday in October -- these are the old USA DST rules, which
were changed even in the US long ago.

So when you use "CET", the C library uses different DST rules from
those used when you omit the timezone.  Thus the discrepancy you
observe.