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

[Max Nikulin]

On 14/01/2023 02:06, Jean Louis wrote:
> This is good for review as related to PostgreSQL database:

I agree that PostgreSQL is an example of good implementation of 
time-related calculations.

> https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

I do not find this section enlightening in the context of this 
discussion. It is more related to storage formats of DB than to higher 
level aspects suitable for applications.

> It would mean that timestamps become time zone aware. Something like this:
>
> <2023-01-15 Sun +1>

Welcome to another set of issues.

First of all, you have just date without specific time point. It may 
mean particular calendar day irrelevant to time zone. ICQ had a bug when 
they decide to store birth dates as timestamps. Significant fraction of 
users received automatic greetings on wrong day, a kind of off by one 
error. So dates must stored as dates omitting time and zone.

Let's assume <2023-01-15 Sun 09:00 +1>

It may be suitable for timestamps in the past, but future is more 
tricky. There is no problem if you are going to watch Lunar eclipse. 
However if your plan is to attend a local event there is a chance that 
you will arrive at wrong time. Sometimes offset of timezones is changed 
and it may happen between the moment when you added a scheduled time and 
the moment of the event.

Notice that Org timestamps already associated with a timezone, the one 
is set in libc (system timezone, or the one set for particular process). 
So daylight saving time and administrative time transitions should be 
taken into account. So Org timestamps may be ambiguous (mostly) 1 hour 
per year around backward time transition, e.g. for timezones having DST. 
This case explicitly specifying time offset helps to avoid uncertainty.