On 21/01/2023 22:55, Thomas S. Dye wrote:
Aloha Max,
Max Nikulin <maniku...@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.
