Tim Cross <theophil...@gmail.com> writes: > The real question is, can the additional complexity associated with > including both a time zone name and an offset be justified in order to > handle the very small number of time stamps which will fall within the > daylight savings transition hour for those locations which have daylight > savings? Keep[ing in mind that the complexity is less to do with the > time stamp format and more to do with using that information in any > meaningful sense. This, combined with the reduced readability of such > time stamps and increased possibility of user confusion leads me to > question if allowing time stamps with both offset and time zone together > in the one time stamp is worthwhile.
As I originally stated in the proposal, the real usefulness of combined offset+time zone is asking Org to double-check the consistency: Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] The time zone rules for Asia/Singapore may or may not remain the same due to political uncertainty. Today, we expect the offset to remain +08. If it changes in future, Org will warn the user. In addition, I find specifying both the time zone and the offset useful for readability: Complex time zones in timestamps will not rely on user's computer having the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London] unambiguously specifies the UTC offset yet emphasizing that the timestamp is related to specific location (Europe/London, but not Europe/Paris). In fact, one may somewhat abuse this format and specify [1916-09-12 12:00+01 @France/Marseille] emphasizing the location. -- 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>