Questions about encode-time and decode-time

Questions about encode-time and decode-time

[Pascal Quesseveur]

Hello,

Due to an error in decoding a date in a Vcalendar apointment, I tried
to understand the coding and decoding of time values. I ended up with
these tests:

(decode-time (encode-time
  (list 0 30 9 13 3 2021 nil -1 "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00")))
-> (0 30 9 13 3 2021 3 nil 3600)
(decode-time (encode-time
  (list 0 30 9 14 3 2021 nil -1 "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00")))
-> (0 30 8 14 3 2021 5 nil 3600)
(decode-time (encode-time
  (list 0 30 9 27 3 2021 nil -1 "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00")))
-> (0 30 8 27 3 2021 6 nil 3600)
(decode-time (encode-time
  (list 0 30 9 28 3 2021 nil -1 "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00")))
-> (0 30 9 28 3 2021 0 t 7200)

I don't understand why I get 8:30 from march 14 to 27.

My config is Emacs 27.1 (x86_64-w64-mingw32) on a french Windows 10
system. I checked with emacs -Q.

-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Questions about encode-time and decode-time

[Pascal Quesseveur]

The problem is only on Windows. I checked with emacs 27.1 on
WSL+Ubuntu and I get correct values.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Questions about encode-time and decode-time

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 23 Mar 2021 19:27:51 +0100
> 
> The problem is only on Windows. I checked with emacs 27.1 on
> WSL+Ubuntu and I get correct values.

Emacs on Windows doesn't support Posix-style DST rules like the ones
you used.  That's because the Windows APIs used for DST don't
understand those rules.  Emacs on Windows supports only the simple
old-style rules like EST-5EDT.

Re: Questions about encode-time and decode-time

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> Emacs on Windows supports only the simple old-style rules like
  EZ> EST-5EDT.

Do you mean I must replace the timezone definition in the call to
encode-time by a string like EST-1EDT? I tried that and got the same
results.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Questions about encode-time and decode-time

[Eli Zaretskii]

On March 24, 2021 9:27:24 AM GMT+02:00, Pascal Quesseveur <pquessev@gmail.com> wrote:
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> Emacs on Windows supports only the simple old-style rules like
>   EZ> EST-5EDT.
> 
> Do you mean I must replace the timezone definition in the call to
> encode-time by a string like EST-1EDT? I tried that and got the same
> results.

Please show what exactly you tried.

Re: Questions about encode-time and decode-time

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> Please show what exactly you tried.

(decode-time (encode-time (list 0 30 9 14 3 2021 nil -1 "EST-1EDT")))

--> (0 30 8 14 3 2021 0 nil 3600)


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Questions about encode-time and decode-time

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Wed, 24 Mar 2021 15:36:44 +0100
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> Please show what exactly you tried.
> 
> (decode-time (encode-time (list 0 30 9 14 3 2021 nil -1 "EST-1EDT")))
> 
> --> (0 30 8 14 3 2021 0 nil 3600)

Thanks.  Please explain what you expected this to yield and why.
(Since EST-1 is not an existing time zone, I cannot myself guess the
answer to that question.)

Re: Questions about encode-time and decode-time

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> Thanks.  Please explain what you expected this to yield and why.
  EZ> (Since EST-1 is not an existing time zone, I cannot myself guess
  EZ> the answer to that question.)

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.

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? 


-- 
Pascal Quesseveur
pquessev@gmail.com

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.

Re: Questions about encode-time and decode-time

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

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

IINM this means that on Windows around mode changes the use of
icalendar can lead to errors. I haven't seen anything in the doc about
it but I think it would be nice to put something about
it.

Unfortunately I am not able to provide a patch. I have simply advised
function icalendar--parse-vtimezone to associate 'wall with timezone
name Romance Standard Time on windows.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Questions about encode-time and decode-time

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Thu, 25 Mar 2021 12:26:28 +0100
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> This has no chance of working correctly on Windows around the
>   EZ> DST change date.  We need some code to convert these DST
>   EZ> specifications to what Windows can understand; patches welcome.
> 
> IINM this means that on Windows around mode changes the use of
> icalendar can lead to errors.

Yes, I think so.  Definitely if those DST strings are being used.

> I haven't seen anything in the doc about it but I think it would be
> nice to put something about it.

I welcome specific suggestions to the documentation about this.  I
myself don't use icalendar, so I don't think I know enough to write
something intelligent.

Re: Questions about encode-time and decode-time

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> I welcome specific suggestions to the documentation about this.
  EZ> I myself don't use icalendar, so I don't think I know enough to
  EZ> write something intelligent.

Until now I only knew the function org-import-icalendar-gnus. So I
don't think I can write any relevant documentation either.


-- 
Pascal Quesseveur
pquessev@gmail.com