emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Nikulin
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Mon, 16 Jan 2023 11:20:43 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]