Max Nikulin <maniku...@gmail.com> writes: > On 14/01/2023 20:08, Jean Louis wrote: >> * Max Nikulin [2023-01-14 10:14]: >>> Let's assume <2023-01-15 Sun 09:00 +1> >>> >>> It may be suitable for timestamps in the past, but future is more tricky. >>> There is no problem if you are going to watch Lunar eclipse. However if your >>> plan is to attend a local event there is a chance that you will arrive at >>> wrong time. Sometimes offset of timezones is changed and it may happen >>> between the moment when you added a scheduled time and the moment of the >>> event. >> Can't follow you. >> with "+1" I would say it is time zone. >> Basic point is that users shall learn to express themselves by using >> time zone. > > "+1" is not a timezone, it is current offset shared by several timezones. You > can not > assure that time offset at a particular location would not change due to new > administrative rules. > > E.g. Europe/Berlin is a timezone, but, strictly speaking, is still > underspecified. Sometimes timezones are split into smaller parts.
Yes, this is a problem. We really want a symbolic TZ specification and we would need 'smarts' i the timestamp generation code that is able to handle potential offset changes due to daylight savings transition etc. Even then, the transition time can change between when the timestamp is set for and when it actually occurs. 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. If on the other hand all the timestamps were in UTC, you avoid lots of these issues. However, you would then also require a 'view' layer/overlay which would take the UTC time, apply whatever the local TZ is and show that result as the timestamp. THis would avoid things being out by an hour due to daylight savings transitions and would mean the user would see timestamps relative to whatever their local time zone is, regardless of changes in location which has also changed time zones. The problem with this approach is that now you have lost the 'plain text' nature of org files. When editing the value, the user would need to remember the value stored in their org file is UTC, not local time. Many exporters would also need to be updated to handle conversion to local time as well.