Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Max Nikulin <manikulin@gmail.com>]

On 16/01/2023 02:14, Jean Louis wrote:
> 
> As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying
> UTC time, so should be Org times also be calculated with underlying
> UTC times.

Org currently can properly handle the following case:

Let's assume that current date is 2022-07-01. A user living in Mexico 
City schedules a local event at 2023-07-01 16:00 (local time, 
America/Mexico_City time zone). That day the region had DST active, so
current time at the moment of appointment creation has the form 
2022-07-01 16:00:00 CDT -0500.

Since that date it was decided to cancel DST transitions, so currently 
(2023-01-16) planned event time is not CDT -0500 but

TZ=America/Mexico_City date -d '2023-07-01 16:00' '+%F %T %Z %z'
2023-07-01 16:00:00 CST -0600

Agenda in Org has no problem as soon as tzdata is up to date.

As a PosgreSQL expert, could you, please, explain how to handle it in 
Postgres?

1. Downgrade tzdata to 2022e version or older, restart Postgres
2. Create a suitable table
3. Store "2023-07-01 16:00" America/Mexico_City timestamp using column 
types you find appropriate for such case
4. Update tzdata to 2022f version or newer, restart Postgres
5. Check that the event is still scheduled at 16:00 in Mexico City

I am interested in the table schema, insert and select commands.

To check timezone data you may use

     zdump  -v America/Mexico_City

Feel free to take another example of tzdata change instead of
https://github.com/eggert/tz/commit/2050724fa1144bacb0d35c7cd9b862da858406c4
that I found it in /usr/share/doc/tzdata/changelog.Debian.gz

I do not want a regression in Org due to a feature that is intended to 
improve timestamp handling. I see the point in the Postgres wiki 
recommendations, but I see their limitations as well. I do not feel that 
time offset and absence of DST can be considered as a settled state for 
the timezone I live in.