Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 15:17, Tim Cross wrote:
>> So far, nobody has shown any reason why using UTC to distinguish the
>> case where the times need to be adjusted and local tz when they don't
>> won't work a a  mechanism that can be used to allow org to handle things
>> better than it does now.
>
> Let's try to move in small steps. UTC as storage format.
>
> An issue with events scheduled as local time in some particular timezone (not 
> your current
> one) and stored as UTC timestamp when IANA tzdata is updated to use new 
> timezone offset:
>
> https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
> Storing UTC is not a silver bullet
>
> Do you think it should be ignored? I faced such issue.

I now think I can see where you have become confused.

I am NOT arguing that all timestamps should be stored in UTC.

I am only saying that when you have a meeting which is not face to face
and involves people from various time zones, the date+time for that
meeting should be stored in UTC. This is the only way org will be able
to ensure the meeting time (which would be converted into local time for
the user) stays relative to the other participants after a daylight
savings transition.

The use cases here is completely different from the example outlined in
that long article.  Firstly, much of the complications arising in that
example are due to tryhing to coordinate dates and times for multiple
parties. Here we are only focusing on 1 party. Secondly, I am only
proposing UTC for meetings where there is no physical location for the
meeting. In the case where there is a physical location, that is a
fact-to-face meeting and it should be recorded in the time zone of the
location of that meeting. In most cases, that will be the user's local
time zone, so for most face=to=face meetings, no explicit time zone is
necessary as the local time zone will be assumed.

So in summary, my argument is

- Use UTC for meetings which are not face-to-face and which involve
  people form different time zones.

- Use the time zone of the location of a meeting when the meeting is
  face-to-face and has a physical locaiton.

- Provide an interface in org to make it easier for users to select the
  correct format (UTC or lcoal/meeting tz). Exactly the best way to do
  this is yet to be determined. It could be just a general solution
  which allows you to select the TZ when you call the functions with C-u
  or it could be something more sophisticated and specific to booking
  meetings which asks questions (i.e. type of record meeting wiard).

- It is assumed that in most cases, timestamps will b displayed to the
  user in their local time zone regardless of how they are actualy
  recorded int he org file.

I suspect where you have become confused is because you read my first
post in the thread where I suggested using UTC for meetings would be
sufficient. However, I revised that based on responses and then proposed
only using UTC for meetings which are not face-to-face and where
participants are from different time zones. It appears you have missed
those posts. 

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. In fact, I would argue that UTC is a
good choice for a majority of time stamps, but acknowledge there are
some situations, notably when scheduling an event with a physical
location, where it is better to use the time zone of the location.