* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 19:23]:
Only occurrences require absolute time, UTC. Events do not.
They follow
the user's space/time.
> > > Org in this state can't handle such things.
> >
> > Org can do the useful thing: translate the UTC timestamp
> > into local
> > time and
> > report both UTC and local time. User will be able quickly
> > to
> > determine if
> > local time is incorrect for some reason, such as DST or
> > travel.
>
> Other way around, it has to translate time stamp into UTC
> time in the
> first place.
Yes, to store the time stamp, Org must take it from the event
time of the
user and translate it to UTC. When reporting an occurrence to
the user,
then Org must translate from UTC to the user's space/time.
User might have
a toggle, like pretty entities, that either shows UTC or
translation to
user's space/time.
That is right. I have stated same.
How do you want Org to know that user's time is in X time zone?
It means, that new settings, variables, functions, must be
introduced
to handle it properly. Timestamp like this one: <2023-01-21 Sat
09:55>
at HTML export will be from 95% and upwards incorrect. To be
correct,
time zone designation shall be placed in HTML export. User could
be in
South America, not in London, that exports it. Time zone UTC
does not
apply for South America. Representation is wrong.
When you say that Org must take it from the event time of the
user,
that means that Org must take some parameter to understand what
time
zone user was.
That means involving functions for export, or sharing of Org
files.
In general, we speak about representation.
You may start making distinctions between "events" and
"occurences",
but technically we speak of time stamps which lack relation to
time
zone in Org. Whatever you "time stamp" without time zone,
representation of it in other time zone becomes difficult, as it
lacks
the fundamental designation of time zone where it was recorded.
And it does not matter if user records time zones in UTC, or
other
time zones.