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

[tomas@tuxteam.de]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Sat, Jan 14, 2023 at 03:05:22PM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
> > Now there's still enough work for the applications to do: presentation,
> > parsing, disambiguation, if necessary asking the user for help. Someone
> > mentioned PostgreSQL -- this is a nice example of what can be done beyond
> > the (comparatively!) boring details of time zone management :-)
> 
> Do I understand correctly that PostgreSQL insists on using timestamps
> with time zone info in favour or ordinary timestamps? Exactly to avoid
> issues with the same timestamp pointing to a different real time from
> epoch depending on the current OS time zone setting?

It doesn't insist: it offers both data types, but the docs are very clear
on what they prefer.

> Thinking more about this, I can see how it can be important for
> clocking, and similar auto-recorded information. Users may be surprised
> to record clocking on some task yesterday just to find the clocking data
> in future upon travelling from Singapore to San Fran.
> 
> So, when implementing time zones, we may need to take care about adding
> the time zone info when auto-inserting timestamps.
> 
> In addition, we may provide some mechanism to set the time zone for:
> 1. Individual files
> 2. For all files, including possible time zone transitions over time.
> 
> What I mean by (2) is when the user travels from, say, Australia to USA,
> it could be possible to say: Use Australia/Seattle up to certain time
> and then use USA/Austin.
> 
> However, the above considerations are just nice-to-haves and should not
> be a blocker to a more generic time zone support in Org. Having an
> ability to specify time zones manually will already cater needs for a
> number of users.

Definitely. But the time stamp (with time zone) in itself doesn't
carry enough context to actually decide that. It's even not that
easy to wrap one's head around dates that "travel" (the easiest
example would be perhaps: "9:00 show up at work" -- when DST takes
effect, it's still 9:00 whatever the local time is). When you
have appointments with people in totally diverse time zones, perhaps
dates tend to be more fixed wrt UTC.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]