Ihor Radchenko <yanta...@posteo.net> writes: > to...@tuxteam.de writes: > >>> ... 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). > > This is basically what we have now - conform to "current" system time > zone. We are not going to remove this timestamp style. Just add an > ability to explicitly specify the timestamps if needed. > >> When you have appointments with people in totally diverse time zones, >> perhaps dates tend to be more fixed wrt UTC. > > AFAIK, people don't usually bother. As long as you can map from specific > time zone (applying the currently active summer clock time changes) to > something like seconds from epoch, you can always calculate back to you > preferred time zone. Look at https://www.emacswiki.org/emacs/Usergroups. > They say, for example, "Europe/Berlin", which may be either CET or CEST. > > In any case, selection of time zone for user timestamps is not something > we need to worry about in Org code. Users are to decide. Org might > assist, but I do not see anything meaningful we can do to help with DST.
I think I basically agree with the last statement. However, perhaps we need to step back and ask ourselves what it is that people do want which drives this feature request. I doubt it is simply the ability to add TZ information to timestamps. I suspect the underlying motivation here is to have org mode actually use this information in a meaningful way, which essentially means all the complicated stuff I'm concerned about and which you seem to imply we wouldn't manage anyway. To put it another way, we need to clarify what people mean when they request the feature of timestamp support in org-mode datestamps. What does this actually mean? Is it as simple as just being able to specify the timezone (seems relatively easy to implement, but doens't really add much) or is the expectation that once you have time zone information, it will be used to do things like adjust date+time in agenda based on change in locale or change in daylight savings status etc. Clarifying the end goal will likely focus the discussion a lot more. My interpretation, which could well be too extreme, is that people want more than just the ability to add TZ info to their timestamps. They want their agenda to reflect correct meeting/schedule times based on their current locale, which may have changed since the initial timestamp was recorded. They want time duration calculations which are able to handle DS transitions etc, they want their agenda/calendar to adjust in a similar way to how their Google calendar will adjust based on DS transitions.
