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

["Thomas S. Dye" <tsd@tsdye.online>]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 21/01/2023 22:55, Thomas S. Dye wrote:
>> Aloha Max,
>>
>> Max Nikulin <manikulin@gmail.com> writes:
>>
>>> On 21/01/2023 07:37, Thomas S. Dye wrote:
>>>>>> 1) Occurrence, where the timestamp includes UTC;
>>>>>> 2) Event relative to user, where the timestamp does not 
>>>>>> include UTC
>>>>>> or a
>>>>>> time zone; and 3)
>>>>>> Event not relative to user, where the timestamp includes 
>>>>>> the
>>>>>> relevant time
>>>>>> zone.
>>
>> I'm curious to find out how the distinction between past and 
>> future
>> makes a difference.
>
> For timestamps in the past "absolute" time is almost always 
> known, so
> beside timezone identifiers like Australia/Sydney it is possible 
> to use
> UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a 
> timestamp in
> future is bound to specific timezone then its identifier must be 
> used
> since the government may change time offset. Of course there are 
> cases
> when UTC or timestamps with fixed offsets are used as well: e.g. 
> Lunar
> eclipse or participants with multiple locations are expected.

Yes, of course!

FYI, lunar eclipse was Ramsey's example of an occurrence, which 
has to do with changes in the relations of things at a time.

>
> So it is "feature" of some timestamps in future that attempt to 
> store
> them in UTC may lead to their invalidation later.

Yes, these are events, which are relative to a timezone, either 
implicit or explicit.

>
>>> As to format for storage timestamps in Org files, particular
>>> timestamps may have
>>> or not explicitly specified timezones, but it is unrelated to 
>>> these 3
>>> cases.
>>
>> I'm curious to learn the classification unrelated to these 
>> three cases
>> used to determine when to store UTC and timezone.
> ...
>>> From my point of view these, 3 cases might be relevant to 
>>> date-time
>>> picker UI,
>>> but not for storage format. While parsing, interpretation of 
>>> each
>>> timestamp
>>> without explicit timezone depends on preferences chosen at 
>>> higher scope.
>>
>> I'm curious what these preferences are, or might be.
>
> Is the following timestamp is in user local timezone or in UTC?
>
> <2023-02-01 Wed 15:00>
>
> If features like the following is implemented then it will not 
> be in
> local time zone:
> - file-local
>
>    #+TIMEZONE: UTC
>    or
>
>    #+TIMEZONE: Australia/Sydney
> - subtree-local
>
>    * H1
>    :PROPERTIES:
>    :TIMEZONE: Australia/Sydney
>    :END:
>
> So looking at such timestamp it would be hard to choose 
> particular case
> from the set you proposed.
>
This might be a feature, not a bug.  A timestamp that does not 
indicate absolute time (UTC or fixed offset) and does not include 
a timezone relies on the timezone set by user.  So user changes 
timezone preference during trips and these timestamps become 
relative to user's local time.

A timestamp with absolute time or with a timezone would ignore 
user's timezone preference.

> Of course it leads to tricky cases when some timestamp is copied 
> to a
> scope with another time zone. It requires some yank handler and 
> text
> properties. When timezone is added to a subtree, perhaps, all 
> timestamps
> inside may need to be changed from implicit timezone.
>
Perhaps the solution here is to consider this a feature, not a 
bug.  When displaying an event timestamp, the timezone should 
always be indicated.  For an event relative to user, this would be 
the preference currently in scope.  For an event not relative to 
user, the timezone will be part of the timestamp.

> For storage format I would use another types
> - explicit/implicit time zone
Yes, explicit for events not relative to user, implicit for events 
relative to user.

> - Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are 
> identical
> to +0000 and +1100 offsets accordingly.

Here, absolute time is best, either UTC or fixed offset from UTC 
(don't underestimate legislators' folly changing timezones).
>
> For UI it is better to choose some terms to make the manual and 
> UI
> dialogues more clear.

Agreed, though I don't have suggestions atm.

> I am not a native English speaker and terms "event", 
> "occurrence" sounds
> confusing for me. E.g. a conference is an event. A regular 
> meeting (even
> when scheduled in another time zone) or "brush teeth" are more 
> close to
> occurrence. As soon as you have to split "event" category into 2 
> parts
> perhaps it is better to pick 3 different names. I may ask for 
> fourth
> that is absolute, but not UTC, but I would prefer to not insist 
> on
> namely UTC and use fixed offset instead.
>
Yes, UTC and fixed offset (from UTC) are two ways of specifying 
absolute time.  Neither one refers to a timezone.

> For UI it is meaningful to name
> - default time zone for this scope (with a hint if it is 
> currently
> system-wide, file-local, or specific to subtree), so no explicit
> timezone will be set.
> - absolute (UTC or fixed offset) preferred for global event
> - bound to location (e.g. Australia/Sydney)
> - ad-hoc timezone that follows user in their trips (close to 
> Ramsey's
> "occurrence").

I think the first and last can be considered identical (see 
above).

Also note that ad-hoc timezone is an event because it specifies a 
timezone, which is a space/time unit.

> The problem is to push users to timezone identifiers for future
> timestamps associated with some location. Offsets must be 
> discouraged
> this case, but encouraged for on-line meetings. For past 
> timestamps
> particular choice is less important. That is why I separated 
> future/past
> timestamps.
>
Yes, good point.

>> Agreed.  The boss needs to inform you what her local time will 
>> be for
>> the meeting by sending you a timestamp with a time zone. 
>> Ideally, Org
>> would know how to associate the timestamp with a recurring item 
>> stored
>> locally.
>
> Unsure it it may be implemented reliably.
Then Org user must understand that repeating timestamp for an 
event not relative to user is fixed to one timezone and is not 
appropriate for an event that might change timezones, as when the 
boss travels but insists on fixing staff meeting to her local 
time.

>
>> Nowadays, I am frequently asked by applications to give 
>> permission for
>> using my location.  When I give it, the application reports 
>> back with my
>> local postal code, etc.  I'm assuming Org can use location to 
>> determine
>> my current timezone.
>
> libc has a concept of timezone. I think, it should be the 
> primary
> source. It is initialized on application startup (roughly) from
> system-wide settings, may be overridden by TZ environment and 
> changed
> later by setting another value of TZ. The problem is that 
> identifier
> like "Australia/Sydney" is considered implementation specific 
> and is not
> directly accessible from the code, it is sealed inside the 
> library.
> Another issue is that I do not know if Emacs is able to receive
> notifications on change of system-wide timezone.
>
> Web-application may request time zone settings from the browser:
>      new Intl.DateTimeFormat().resolvedOptions().timeZone
>
> Android devices may have outdated and incomplete zoneinfo 
> database. This
> case either computations should be performed on the server or 
> tzdata
> copy should be bundled into the app.
>
> Client-server application may use resources maintained on 
> servers, emacs
> must be able to run off-line and enough user will be unhappy 
> noticed
> some outgoing queries.
>
> Ubuntu installer or e.g. Google relies on GeoIP databases.
>
> Geodata for timezones is available, but laptops or desktops 
> mostly do
> not have GPS receivers. IP behind NAT is not useful to determine 
> location.
>
> It is possible to make GeoIP database (quality of ones available 
> for
> free are not high) and map of timezones, but I do not think it 
> is
> reasonable.
>
> I suppose, system timezone would be enough for Org. Third party 
> packages
> might implement another way.

Thanks.  Much appreciated.  So, Org user will need to understand 
that timezone calculations will only be as current as libc and 
that user is responsible for setting local timezone.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye