Subject: Re: Idea for handling timezones
Date: Fri, 23 Apr 2021 09:54:00 +0200 [thread overview]
Message-ID: <20210423075400.GB10750@tuxteam.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]
On Fri, Apr 23, 2021 at 09:45:14AM +0800, Shironeko wrote:
> Hi all,
> I originally thought having the timezone in the header of the file would make
> things simpler, since it meant all the timestamp would be in the same timezone,
> rather than potentially different ones. But it seems that that might not be
> inline with how others use their org files.
> org actually already has a keyword for a per entry timezone,
> The problem with it is that no other facility of org plugs into that, it only
> counts when exporting into other calendar systems, which I think is strange. If
> it is indeed better to be able to set timezone per entry, then I think
> supporting this properly in org would be best.
Interesting idea. If I understand the doc correctly, the iCalendar
exporter picks up timezone information from a property of the
"enclosing" heading, if present.
> Only having CST etc timezone abbreviations is indeed problematic, because it is
> ambiguous and kinda difficult to enter, also people don't necessarily
> communicate with the correct designation (maybe they mean EDT but used EST, but
> the time is unambiguously EDT).
They seem more fragile than time offsets, yes. Much implicit environment.
Some folks seem to still have strong preferences for that (not me, mind
> With repeat tasks I don't think it would be a problem for tasks that repeats
> daily or longer (since by definition they add to the day/month/year directly,
> not counting how many days there are in a month for example). For hourly
> repeating tasks it is indeed ambiguous, but I don't have an idea on what would
> be better. Maybe people that have those can chime in.
Actually, repeating tasks are clear use cases for those "mushy" time
zones: "we meet every second and fourth Thursday every month at 19h30"
almost surely means "at whatever time the local clocks say it is half
past seven in the afternoon", so daylight saving corrections will
Decisions, decisions :-)
Don't get me wrong: I'm not trying to discourage you to pick that up,
I'm happy someone has the spirit to do so!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2021-04-23 7:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 7:40 shironeko
2021-04-02 11:34 ` tomas
2021-04-03 0:36 ` Shironeko
2021-04-03 7:56 ` tomas
2021-04-03 8:03 ` shironeko
2021-04-03 8:30 ` tomas
2021-04-03 9:26 ` Shironeko
2021-04-03 11:23 ` Greg Minshall
2021-04-03 15:00 ` Russell Adams
2021-04-03 18:51 ` Greg Minshall
2021-04-03 20:06 ` Samuel Wales
2021-04-03 22:47 ` Tim Cross
2021-04-04 0:51 ` Tom Gillespie
2021-04-04 16:06 ` Maxim Nikulin
2021-04-23 1:45 ` Shironeko
2021-04-23 7:54 ` tomas [this message]
2021-04-03 12:43 ` tomas
2021-04-03 12:47 ` Shironeko
2021-04-03 13:20 ` Shironeko
2021-04-02 23:37 ` Tim Cross
2021-04-03 0:31 ` Samuel Wales
2021-04-03 0:43 ` Shironeko
2021-04-03 0:53 ` Samuel Wales
-- strict thread matches above, loose matches on Subject: below --
2021-03-31 2:23 Shironeko
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).