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.
