On Sat, 2021-04-03 at 10:37 +1100, Tim Cross wrote: > > 1. Timzone alone is not sufficient. Offsets from UTC change due to > daylight savings times etc. > > 2. You can easily have timestamps from different timezones in the same > org file > > 3. Storing timestamps in local time is problematic because of the > inherent ambiguity this can have (again, due to daylight savings times > and what occurs at the 'cut over' time). > > 4. Sometimes, you may want the timestamp to reflect the date/time as it > was when recorded and don't want it to 'change' because your now viewing > it in a different timezone etc.
1 and 3 is addressed by the use of tz database, it makes sure the timezone conversion is lossless. 2 and 4 is really not the target for this proposal, this feature is completely optional and this is really meant to solve the "I want to see when I need to get my tasks done" which is a particular headache when there is timezone involved. > Personally, I think timestamp 'storage' and timestamp 'display' need to > be treated separately. I also think all relevant information (timezone, > offset) need to be stored with the timestamp. I also think the > fundamental base timestamp should be stored as UTC, allowing all time > calculations to be consistent (free of daylight savings time changes). > The user can then manage how the value is displayed by setting timezone > and offsets as appropriate (with perhaps the default being the local > system settings or whatever offset/tz was stored with the timestamp > itself). > > It is very difficult to predict or understand all the use cases for > timestamps. Therefore, any scheme must be extremely flexible. Experience > has taught me that one critical component is that at the lowest level, > many problems are avoided if the value is in UTC. Problem is, UTC is not > terribly human friendly. Luckily, this can largely be automated for many > common use cases. Unfortunately, it does also mean that if you are > someone who frequently moves between many timezones, your situation will > be more complicated. > > ne of the most frustrating parts of working with timestamps is daylight > saving times. This causes complications at so many levels. In > particular, I hate the fact change over dates often change and more > often than not, those changes are based around politics and at the whim > of politicians, which makes programatic handling more complex than it > needs to be. > yes, this is why I want to avoid changing the timestamp itself, since that will never lead to working solutions soon. Regards, shiro
