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: Sun, 22 Jan 2023 19:14:06 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.

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

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.

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.

For storage format I would use another types
- explicit/implicit time zone
- Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are identical to +0000 and +1100 offsets accordingly.

For UI it is better to choose some terms to make the manual and UI dialogues more clear.

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.

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").

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.

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.

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.




reply via email to

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