Org timestamps infamously do not support them.
I can't imagine using a todo application which lies to me half a year and every time I travel.
So? Emacs has built-in solar and lunar calendars, has world-clock command, format-time-string accepts ZONE argument. Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones? This can be done in less than 15 minutes. With AI maybe in 20.
You're not dealing with an app you paid for, and your complaint not even an accurate one: Org's timestamp format doesn't encode timezone by default. Emacs absolutely supports the feature you want, you just didn't know about it.
Last time I checked, proper timezone support wasn't there. One could specify single timezone for entire org engine, but not per timestamp. I found some nearly official mailing list thread where participants couldn't settle on a single solution, and so the conclusion was that proper TZ is not coming to org.
> Org's timestamp format doesn't encode timezone by default
> format-time-string accepts ZONE argument
Isn't format-time-string just a visual decoration? Last time I checked, agenda and all other plumbing always treated every timestamp as local (to the TZ configured globally). And so if I recorded that I have a meeting at 1PM London time, my org-agend would show it to me 1PM even if my TZ is set to New York.
> Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones?
Can you elaborate? My understanding was that I'd need to rewrite entire org in order to support time stamps with mixed time zones embedded in them.
> You're not dealing with an app you paid for
Actually, I'd be willing to pay above the competitor _subscritpion_ price for an org-based organizer with
- proper TZ support
- conflict-free sync between devices
- (cherry on top) touch UI friendly Android client. But honestly, orgzly would do, as long as it supports the above
a) you need to see the timestamp in different timezone(s)
A minor mode with home-zone/visiting-zone vars showing dual times via overlays answers: e.g. "It's 1PM here, what's that in London?" That's the world-clock problem. Useful, easy to solve in ~15 min.
b) anchor an event to a foreign zone permanently - you want to record a fact about an event that is intrinsically tied to a zone
For that, yes, you'd have to either change a bunch of things about Org-mode - every consumer of timestamps (agenda, clock, deadlines, repeaters) would need to become zone-aware.
Pragmatically, you can store the zone without rewriting Org, by piggybacking on a property/tag and a conversion step.
1. Author in foreign zone, but store normalized to one canonical zone (e.g. UTC) in the timestamp, and keep the original zone in a property:
* Meeting
:PROPERTIES:
:TZ: Europe/London
:END:
<2025-06-01 12:00> ; UTC
The limitation is that all the timestamps within a single heading can only be of a single timezone.
---
There's yet another alternative - you can codify the TZ on each timestamp as a propertized text. The problem? Text properties don't get persisted, so you'd have to add custom logic that mangles the timestamps in the file on save (essentially breaking them for all dowstream consumers), and then restores them to normal shape with propertized timezone info. I guess this begets another problem - many Org operations reconstruct the timestamp string from a parsed org-element struct.
I guess, I do stand corrected - if the problem you want to solve is "b" - there isn't a straightforward solution to it.