On 22/01/2023 04:29, Tim Cross wrote:
Max Nikulin writes:
- UTC is a recommendation for planning when participants are scattered over
multiple
timezones.
- You admit that some timestamps in your files may be specified as time zone
identifier +
local time relative to this zone.
- In both cases you may configure overlays to use local timezone or another one
whatever
you currently find convenient.
- Time chooser offers several time zone options.
That seems to be in-line with what I was arguing, so yes, would agree.
Great. At this stage my goal is to convince people that local time and
UTC for future timestamps are not enough for real life use cases.
Arbitrary timezone may be crucial to arrive at proper time despite it
matters in rare cases. My concern is mostly storage format, timestamp
syntax in Org files.
On 21/01/2023 06:38, Tim Cross wrote:
I would also argue UTC is good for 'traditional' timestamps which record
a specific point in time and for situations where you want accurate
calculations of time durations.
Let's consider the following timestamp
[2023-01-22 Sun 08:29@+1100]
"@" is unimportant here, I take it from Ihor's examples. This timestamp
is from the "Date:" header of your message. It is not UTC, but in my
opinion it is equally precise (disregarding seconds) to a UTC timestamp.
Would you prefer to have timestamps in your files in such form or as
[2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat
21:29@+00:00], etc)?
Maybe [@1674336588] (seconds since epoch)?
I consider storage format as a part of Org UI, so I believe that
[2023-01-22 Sun 08:29@+1100] with offset of the usual time zone is more
convenient than [2023-01-21 Sat 21:29@+0000]. Overlays may present your
local time in both cases, but raw value with usual offset is easier to
comprehend.
When a file is shared by a group of people spread across the globe, they
are free to use UTC or another fixed timezone or do not care at all
concerning particular offset, it just should present.
Postgres has a reason to insist on UTC since timestamps are stored in
binary format as microseconds since epoch. It is important for
performance and there is no room to specify offset. Org has to parse
timestamps from strings anyway, so it is better to use format more
convenient for humans.
A side note. In my opinion, *by default* timestamps should be created in
local time with no offset or timezone. There are should be some
preferences to enable absolute timestamps and a function to fix offsets
or timezone identifiers for existing timestamp when the user realizes
that they become necessary (e.g. before a trip).
So I do not see any advantages of UTC in comparison to time offset
specific to particular time zone, usually user's local one. My vote is
[2023-01-22 Sun 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of
course, only in cases when identifiers like Australia/Sydney do not
matter) with a configuration option with timezone used fix offsets in
stored timestamps.
