what i proposed is this. which uses text properties. it might not suit your needs, but might be a workaround. at least it is a brainstorm. suitable for wrapping fish.
1] convert all your tses to utc [exercise for the reader] 2] make org's idea of time be utc [there /might/ be code] 3] make org display local time and tz [see below] 3 is customizable: (info "(org) Custom time format") On 4/2/21, Shironeko <shiron...@tesaguri.club> wrote: > 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 > > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html