[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezon
From: |
Max Nikulin |
Subject: |
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode) |
Date: |
Sun, 22 Jan 2023 15:35:42 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
Thomas, notice that I resumed a postponed earlier part of discussion
related to timestamps in the past. Offset from UTC is almost always well
defined this case.
My perception is that discussing timestamps in future, we came to
agreement with Tom that timestamps can be specified with timezone
<2024-02-22 08:29@Australia/Sydney>, in UTC <2024-02-21
21:29@UTC>, or in local timezone <2024-02-22 08:29>
Now I had a hope to convince at least some participants that explicit
time offset may be used interchangeably with UTC. It is applicable to
timestamps in the past and to future timestamps when the person who
created appointment respects remote participants, so decided to rule out
DST and fix absolute time.
On 22/01/2023 13:17, Thomas S. Dye wrote:
UTC is not a timezone. It is absolute time.
I do not see any point to consider UTC too special.
Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun
08:29@+1100] specify absolute time. "+1100" means 11 hours, not
particular location. Do you have an example of a case where I am wrong?
I use the term "time zone" as a set of rules how to calculate offset at
particular time moment. UTC is a degenerate case of fixed zero offset.
In this sense "+11:00" is not a timezone, it is time offset. Several
time zones (as set of rules) may have such offset at some specific time
moments including "Etc/GMT-11" that is a timezone.
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).
I don't think there should be a default.
Unfortunately hard choice of default value or behavior is unavoidable
during development of software. Consider a user who just have installed
Org. Till it is explicitly configured, perhaps it is better to add e.g.
clocking entries without offset or timezone assuming local time. It
should be possible to change it later.
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.
The disadvantage of time offset specific to a particular timezone is
that the timezone offset wrt UTC can change arbitrarily. This is a
potential problem if the arbitrary change takes place between the
creation of the timestamp and the happening it identifies. In contrast,
UTC is guaranteed not to change. It is not a timezone, it is absolute
time, a pure continuum. It is a requirement of occurrences.
I consider the case when offset is already known because it is a time
moment in the past. Besides rare corner cases offset can be considered
as a part of authoritative data. Timestamps like [2023-01-22 Sun
08:29@+1100] can be unambiguously mapped to UTC.
I'm not sure offset is necessary for events, given that offset can
change arbitrarily. WDYT? It seems to me that once an event has been
tied to a particular time in a particular time zone that Org's job is to
take into account changes to that timezone, such as DST and arbitrary
legislation. These changes in the event's timezone need to be
propagated through the schedule for each user, so it is possible to
synchronize local timestamps around the globe.
For timestamp in the past offsets simplifies calculation of duration.
Offsets may be used to fix absolute time before changing location when
time zone was omitted. Perhaps I will add more in another part of this
thread.
After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may tell
more than [2023-01-22 Sun 08:29@Australia/Sydney].
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, (continued)
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Max Nikulin, 2023/01/21
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Thomas S. Dye, 2023/01/21
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Max Nikulin, 2023/01/22
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Max Nikulin, 2023/01/22
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Thomas S. Dye, 2023/01/22
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Tim Cross, 2023/01/20
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Max Nikulin, 2023/01/21
- Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda, Tim Cross, 2023/01/21
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Max Nikulin, 2023/01/22
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Thomas S. Dye, 2023/01/22
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode),
Max Nikulin <=
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Thomas S. Dye, 2023/01/22
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Jean Louis, 2023/01/23
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Thomas S. Dye, 2023/01/23
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Max Nikulin, 2023/01/23
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Thomas S. Dye, 2023/01/23
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Max Nikulin, 2023/01/23
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Jean Louis, 2023/01/25
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Ihor Radchenko, 2023/01/24
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Thomas S. Dye, 2023/01/24
- Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode), Max Nikulin, 2023/01/26