Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis <bugs@gnu.support>]

* Stefan Nobis <stefan-ml@snobis.de> [2023-02-03 18:50]:
> Jean Louis <louis@gnu.support> writes:
> 
> > Specifying time zone is not ambiguous as long as you use the TZ
> > database for specifications!
> 
> That's wrong and you know it.

What I know is based on research and good references. It seems you did
not follow it.

> For example
> 
>    [2023-10-29 02:30 @Europe/Berlin]
> 
> is ambiguous. Period.

You may put as many periods as you want.

If you do not know how to generate timestamp that they are conclusive,
then they will be always invalid or ambigous.

Computer program that knows that your timestamp is most probably try
to correct it, as saving time with invalid timestamp with some
programs does not work, as I have demonstrated.

Fact is that some timestamps mentioned in the conversations are
invalid. 

Such invalid timestamps were generated by human, not by computer.

Agree on what people internationally agreed.

Do not generate it in first place.

I can place any kind of text anywhere and I could say it is
"timestamp", but that is valid for me, not for community that relies
on international agreements.

If user wish to do timestamp generation by hand, or some looney
program wish to generate invalid timestamps, I can only say "good
luck", but it is good to warn users and file bug reports for such
program.

Timestamp of course may be generated by human, and it can be ambigous. 

But why would you do that? 

Isn't it better to learn how to write non-ambigous timestamps?

Or even better, to use good program to generate non-amgibious
timestamp?

Every user and programmer should strive to make computer, in this case
Org program, to generate and calculate useful timestamps and how to
increase that usefulness for users by being accurate.

Programmer should not strive to generate invalid timestamps, and then
prolong discussions how timestamp is invalid.

That is programmer's problem. 

We have that problem in Org, solutions are in sight.

It is not international problem at all as it is solved by ISO
representation.

All computer programs should use the internationally accepted time
zone database and not those invalid timestamp representation but valid
timestamp representation.

And user should file bugs when they see that timestamps are either
incorrectly represented, invalid, or there are some problems.

It is easy to observe how will PostgreSQL understand those times with
time zone being Europe/Berlin:

Here it will tell that time of 01:30 has UTC offset of +02:

select '2023-10-29 01:30:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 01:30:00+02
(1 row)

Here it will tell that time of 02:30 has UTC offset of +01:

select '2023-10-29 02:30:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 02:30:00+01
(1 row)

Here it will tell that time of 02:30 has UTC offset of +01:

select '2023-10-29 03:30:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 03:30:00+01
(1 row)

Observe how the timesamp representation changes 
from '2023-10-29 01:59:59+02' to '2023-10-29 02:00:00+01'
and how UTC offset is there to make it very clear.

select '2023-10-29 01:59:59'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 01:59:59+02
(1 row)

select '2023-10-29 02:00:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 02:00:00+01
(1 row)

Above is happening because PostgreSQL observes time zone definition
and knows how to represent that timestamp correctly.

A looney program will not observe time zone, it will generate invalid
or ambigious timestamps.

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

Do use looney programs.

Use timezone database information and international standards to
represent and exchange time related information.

> It would also be nice to eventually recognize, that we are talking
> about readable syntax for humans, that is sometimes generated,
> sometimes manually typed. Most of you comments does not really
> resonate with this crucial design goal.

Teach that human how to represent time correctly.

Teach computer program to help human to correct incorrectly hand
written timestamps to something that is reasonable, like Etar calendar
does that.

-- 
Jean

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

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