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.