Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

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.