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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> 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)?
>

It really depends on what the timestamp is for as to what my preference
would be.  For example, timestamp for an email message is likely best as
your initial example or date with remote senders TZ. Timestamp for a log
record I would probably want <YYYY-MM-DD HH:MM Z> or one of the
variants because the most common way I use those types of timestamp is
in diagnosing problems and comparing revords from various locations
where I don't care about the local time where the record was generated,
but with when it occurred in relation to other log recores.  

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

I would argue that all depends on how you use the information. My org
files are consumed by me (reading) and by scripts, elisp and other
programs. 

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

Guess I agree, but this is such a rare/small use case, I really don't
consider it terribly relevant. While I do share data relating to
projects I work on with others, I am the only one who uses org mode and
I suspect I'm the only one who uses Emacs. Sharing org mode files simply
isn't a use case I need to worry about and sharing timestamp data from
those files is rare as well - if I do need to, they will likely be
processed into some other more standard format anyway. 

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

Again, depends on the use case and how you use the data. 

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

My preference is for a timestamp syntax which lets the user select the
format they want and not attempt to restrict it more than that. Provided
you can specify timestamp with and without TZ information and you
support full and abbreviated time zone names as well as UTC, I don't
think it mattters - let the user choose what suits them best. I
definitely have use cases where timestamp in UTC is the most convenient
format. 

My default would be without time zones, but enable easy adding of
timezones when needed e.g. by calling the function with C-u.

The availability of configurable display overlays would be very useful,
but you also need to be able to turn that off easily and you probably
need an easy way to temporarily update/change the overlay format.