Item — HN Reader

> Org timestamps infamously do not support them.

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.

1 comments

Oh, you can't imagine how I'd like to be proven wrong.

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

So the problem is two-fold, right?

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

2. A small minor mode renders the display via overlay in either the stored :TZ: or your current zone, computed with `format-time-string … zone`.

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.

Aren't Org mode dates ISO 8601? ISO 8601 has an optional timezone, is that not supported in Org mode? You could then use format-time-string to configure how it is displayed.

Another possible solution. Often - but not always - a datetime and timezone pair can alternatively be represented as a UNIX timestamp. Depending on the use case there are tons of ways to manipulate UNIX timestamps, and Org mode might support that naively (I'm not sure, try it).

Thanks for the detailed explanation, I really appreciate it!