[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea for handling timezones
From: |
Shironeko |
Subject: |
Re: Idea for handling timezones |
Date: |
Sat, 03 Apr 2021 08:43:47 +0800 |
User-agent: |
Evolution 3.38.4 |
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
- Re: Idea for handling timezones, (continued)
- Re: Idea for handling timezones, Tim Cross, 2021/04/03
- Re: Idea for handling timezones, Tom Gillespie, 2021/04/03
- Re: Idea for handling timezones, Maxim Nikulin, 2021/04/04
- Re: Idea for handling timezones, Shironeko, 2021/04/22
- Re: Idea for handling timezones, tomas, 2021/04/23
- Re: Idea for handling timezones, tomas, 2021/04/03
- Re: Idea for handling timezones, Shironeko, 2021/04/03
- Re: Idea for handling timezones, Shironeko, 2021/04/03
Re: Idea for handling timezones, Tim Cross, 2021/04/02
Idea for handling timezones, Shironeko, 2021/04/02