Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-02-01 14:12]:
> Let me try to explain better. Just specifying time zone is ambiguous
> once per year during daylight transition.

For reason to make it unambiguous, people (representatives of
countries in international associations) are creating the TZ database,
and maintaining it.

Specifying time zone is not ambiguous as long as you use the TZ
database for specifications!

> [2023-03-29 02:30 @Europe/Berlin] is special.

I may only guess you wanted to specify the last Sunday in March 2023,
where there is UTC offset shift.

Your time stamp above is very valid, but you probably wanted to point
out to the alleged problem with the daylight savings.

The time stamp you maybe wanted to demonstrate would be:

2023-03-26 02:30 @Europe/berlin

It is not special case!

It is INVALID time stamp. 

It does not exist in the context of internationally agreed time.

In the context of this e-mail, you may write what you want, but you
are arguing about something that does not exist.

Things that do not exist, do not make you a problem. 

The only thing that could be ambiguous is the hypothetical, imaginary,
lousy software that generates invalid time stamps like that.

You are bringing up the problem which in the human agreed reality does
not exist.

> According to https://www.timeanddate.com/time/zone/germany/berlin,
> 2023-03-29 is the time when the clock is shifted one hour back due to
> the daylight saving transition. The wall time goes like
> 
> 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... ->
> 2:30 (again!)

I got your point, even though you are showing invalid time stamp. 

And that is not a problem, because TZ database specifies exactly how
to calculat time.

If you however, use time zones but do not use time zone database,
well, that is case of bad program design, and your program, and
anything you do in that program will become ambigous as well.

> So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points:
> before and after the transition.

1. Your timestamp is wrong for demonstration purposes, the time stamp
   you are displaying is not related to daylight savings shift.

2. The time stamp for demonstration should be: 
   2023-03-26 02:30 @Europe/berlin

3. The time stamp above, in the number (2) of this list, IS INVALID.

4. Recommendation is to stop using lousy programs generating invalid
   time stamps.

> Specifying explicit offset is thus necessary in this specific
> scenario to disambiguate the timestamp:

That specification of UTC offset is necessary is out of any doubt.

But you have formed your decision in invalid timestamp and lousy
programs, thus further conclusions based on such decisions cannot be
relevant, and people shall be cautious regarding conclusions that were
based on wrong and correct time stamp, where author wanted to point
out to daylight savings shift time stamp, whereby such time stamp is
invalid and as time representation does not exist.

It is because you do not need to worry how time zone is ambigous,
because it is not. Please read specification of the time zone
definition. It has been defined to solve this type of problems for
people.

> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)

Both of the above time stamps do not exist, both are valid.

If you meant daylight savings time stamps, then you maybe wanted to
say following:

> [2023-03-26 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-26 02:30+1 @Europe/Berlin] (after transition)

However, above time stamps are INVALID. 

You deal with non-existent problem.

There is nothing to solve there.

Practical exercises for people to understand it:
------------------------------------------------

Go in shell:

# Following will set your user's time zone to Europe/Berlin, that
# indicates that programs shall look for time zone specification, such
# as the one in /usr/share/zoneinfo/Europe/Berlin

$ export TZ=Europe/Berlin

# In the next step, setup the date:

$ sudo date -s '20230326 0159'
Sun Mar 26 01:59:00 AM CET 2023

# Ask for current time stamp from system

$ date
2023-03-26-01:59:22-Sunday

# Sorry that I have peculiar system time stamp personally, it is
# because I often use it to generate files

# Let us see it without my customization

$ /usr/bin/date
Sun Mar 26 01:59:06 AM CET 2023

# Let us repeat it, while we let time running:

$ /usr/bin/date
Sun Mar 26 01:59:32 AM CET 2023

# Observe what is happening:

$ /usr/bin/date
Sun Mar 26 01:59:58 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 01:59:58 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 01:59:59 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 03:00:00 AM CEST 2023

Did we arrive to 02:30? No. Why?

How about setting up the date to the imaginary "ambigous" and invalid
time stamp:

$ sudo date -s '20230326 0200'
date: invalid date ‘20230326 0200’

$ sudo date -s '20230326 0230'
date: invalid date ‘20230326 0230’

Hmm. Maybe the GNU `date' command simply does it's job well?

I wonder why?

Maybe it uses time zone specification?

And following will work:

$ sudo date -s '20230326 0300'
Sun Mar 26 03:00:00 AM CEST 2023

The demonstration will tell you that specifying invalid time stamps is
what? INVALID.

To avoid such time stamps is easy, just stop using crapy programs to
generate invalid time stamps.

File a bug, complain, but do not use wrong time.

Another practical exercises user can do:
----------------------------------------

1. Go to https://f-droid.org
----------------------------

   Try out the free application Etar, and try to enter such invalid
   time stamp by creating a task with the time of [2023-03-26 02:30
   @Europe/Berlin] and user will see that it will not work, the time
   will be written as 3:30 instead of 2:30 -- application is not
   lousy, thank you very much, PASS!


2. Do PostgreSQL exercise in shell:
-----------------------------------

$ psql
psql (14.6)
Type "help" for help.

[local] maddox@rcdbusiness=# set timezone to 'Europe/Berlin';
SET

[local] maddox@rcdbusiness=# select '2023-03-26 02:30'::timestamptz at time 
zone 'Europe/Berlin';
      timezone       
---------------------
 2023-03-26 03:30:00
(1 row)

The exercise will show that when user specify invalid time stamp
program recognizes it and assumes that one hour must be added to such
invalid timestamp. PASS for PostgreSQL!


3. Google Calendar on Android phone
-----------------------------------

I have asked friend to try to setup a task at 02:15 and Europe/Berlin
time zone:

Attempt to setup tasks worked by itself:
https://gnu.support/images/2023/02/2023-02-01/Screenshot_20230201-154514.jpg

But as soon as the task was saved, the specified time shifted 1 hour
forward:
https://gnu.support/images/2023/02/2023-02-01/Screenshot_20230201-154527.jpg


Conclusion:
-----------

1. Time stamp like [2023-03-26 02:30 @Europe/Berlin] is invalid. There
   is no problem at hand unless there is lousy program generating it.

2. People taking care of time should not use lousy programs generating
   invalid time stamps.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/