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

[tomas]

On Sun, Jan 15, 2023 at 06:43:19AM +1100, Tim Cross wrote:
> Max Nikulin <manikulin@gmail.com> writes:
> 
> > On 14/01/2023 20:08, Jean Louis wrote:
> >> * Max Nikulin [2023-01-14 10:14]:
> >>> Let's assume <2023-01-15 Sun 09:00 +1>
> >>>
> >>> It may be suitable for timestamps in the past, but future is more tricky.
> >>> There is no problem if you are going to watch Lunar eclipse. However if 
> >>> your
> >>> plan is to attend a local event there is a chance that you will arrive at
> >>> wrong time. Sometimes offset of timezones is changed and it may happen
> >>> between the moment when you added a scheduled time and the moment of the
> >>> event.
> >> Can't follow you.
> >> with "+1" I would say it is time zone.
> >> Basic point is that users shall learn to express themselves by using
> >> time zone.
> >
> > "+1" is not a timezone, it is current offset shared by several timezones. 
> > You can not
> > assure that time offset at a particular location would not change due to new
> > administrative rules.
> >
> > E.g. Europe/Berlin is a timezone, but, strictly speaking, is still
> > underspecified. Sometimes timezones are split into smaller parts.
> 
> Yes, this is a problem. We really want a symbolic TZ
> specification and we would need 'smarts' i the timestamp generation code
> that is able to handle potential offset changes due to daylight savings
> transition etc. Even then, the transition time can change between when
> the timestamp is set for and when it actually occurs.

Having wrangled that (outside Emacs) for a while, I politely disagree.

If it's the past we are talking about, the offset is most of the time
the right thing (we know best at timestamp creation time). When it's
the future /and/ we are talking about local time, then the symbolic
time zone makes more sense (e.g. we meet in Lviv next Monday at 3pm,
whatever 3pm is in that timezone).

I think we need (optionally) both. Well knowing that some dates with
some symbolic time zones are ambiguous.

For a log file (past times), for example, I would insist in having the
offset (actually I'd try to talk people into having UTC, but have failed
at times with that).

Cheers
-- 
t

signature.asc
Description: PGP signature