Tim Cross <theophil...@gmail.com> writes: >> 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.
I don't imply that. What I am saying is that we first need to decide on syntax and provide basic support for time zones. It will already be helpful as I won't need to convert timestamps into local time or think if I need to convert timestamps ahead of time before a flight to different time zone. More things can be implemented once we have the basic support. > 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. Converting timestamps with time zone to local time is indeed one of the basic features we need to support. > 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. I do not see any obstacle to having these basic features either. We already use `encode-time' in time calculations across Org. So, all the operations on times already use internal time representation. We will get all the features you named pretty much for free just by supplying time zone to `encode-time' calls. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
