Ihor Radchenko <yanta...@posteo.net> writes: > Tim Cross <theophil...@gmail.com> writes: > >> Unfortunately, the common abbreviated forms like EST, AEST etc are >> inconsistent here. Some places will have a standard and a daylight >> savings type i.e. AEST and AEDT, while others will have just AEST. TO >> make it worse, two locations with the same time zone offset my use >> different versions i.e. Australia/Melbourn is AEST (+10/+11) and >> Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is >> just AEST (+10). If everywhere which has daylight savings ensured they >> used a different abbreviation for daylight saving and non-daylight >> saving times, life would be easier, but they don't). Then of course >> there are many countries which don't have a symbolic letter abbreviation >> i.e. just have e.g -05 as their abbreviated TZ name. >> >> It is this and other related reasons why just relying on Emacs' internal >> API for times and dates is not sufficient. The abbreviated times have >> ambiguity and the full timezone specification is cumbersome and >> ugly. Even worse is that issue won't be shown up as failures - you will >> just silently get wrong results. > > So, basically we may need a way to (1) identify ambiguous TZ > specifications; (2) signal to user about potential issues. > > Note that these are also optional features we may implement any time > once we have basic timezone support. > > For (2) we may use something similar to `world-clock' - display user > timestamp at point for different time zones. Maybe via eldoc.
If the timestamp only contains the abbreviated name e.g. AEST, then there is no automatic way to disambiguate - best we could do is issue a warning. The abbreviated TZ name, unlike the full TZ name, is really just a shorthand for the time offset from UTC at a specific point in time. The full TZ name on the other hand states not only the UTC offset, but also the TZ rules (and with things like the IANA TZ database, the specific TZ rules in place at the point in time that timestamp represents). This is essentially Max's main point - if timestamps for the future have the full TZ name, then we can manage things like changes in TZ database rules which occur after creation of the timestamp or adjusting timestamps (for scheduled tasks) based on changes in location etc). This would not be possible with abbreviated TZ or just UTC offsets. As an example, I'm in Australia/Brisbane TZ and I create a timestamp. If it only has the AEST TZ info, when I travel to Australia/Melbourne org would not be able to identify I'm in a TZ with an offset of +1100 rather than +1000 because both use AEST (for NSW it likely would work as NSW uses AEDT during daylight savings time). However, if the TZ was full name i.e. Australian/Brisbane, then it does know and can adjust because my local TZ has changed to Australia/Melbourne. So I guess the timestamp format and the code which manages them will need the ability to use the full TZ name and not just the abbreviated form (and I guess an option to allow the user to select). In fact, we probably need a way to select between abbreviated/full dynamically as well as you might use the different TZ types as a way to flag which timestamps you want to adjust due to TZ changes (either in TZ db or in user location) and those you don't want changed. I also note a comment from an earlier thread regarding timestamps and historical changes in tz info. I don't think this is an issue. As far as I know, past TZ rules/information rarely, if ever, change. It is only with respect to future dates it is a problem and I doubt there is much that can be done. For example Postgres recognises that a future timestamp may become incorrect due to changes in TZ rules post creation of the timestamp, but they specifically state they don't handle that situation and that their model has an implicit assumption that the TZ rules associated with a TZ don't change. In other words, from their perspectrive, you would have to have a different process which monitors TZ database information and when it changes, examine your db of timestamps for ones which have been affected and adjust accordingly (assuming it matters enough of course). I think org could eventually reach a middle ground - if a future timestamp has the full tz name, then changes can be applied, but if not they cannot and leave it to the user to decide which is used.
