From: Samuel Wales <samologist@gmail.com>
To: Shironeko <shironeko@tesaguri.club>
Cc: Tim Cross <theophilusx@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Idea for handling timezones
Date: Fri, 2 Apr 2021 17:53:54 -0700 [thread overview]
Message-ID: <CAJcAo8v-S4Gdaq25yVZCS186J-R+ACsrfX8S8yuS0HyDf439VQ@mail.gmail.com> (raw)
In-Reply-To: <1fdca9a5e7e91136d0c4b8d6a38d2ca3dbc0f7d4.camel@tesaguri.club>
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 <shironeko@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
next prev parent reply other threads:[~2021-04-03 0:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 7:40 Idea for handling timezones shironeko
2021-04-02 11:34 ` tomas
2021-04-03 0:36 ` Shironeko
2021-04-03 7:56 ` tomas
2021-04-03 8:03 ` shironeko
2021-04-03 8:30 ` tomas
2021-04-03 9:26 ` Shironeko
2021-04-03 11:23 ` Greg Minshall
2021-04-03 15:00 ` Russell Adams
2021-04-03 18:51 ` Greg Minshall
2021-04-03 20:06 ` Samuel Wales
2021-04-03 22:47 ` Tim Cross
2021-04-04 0:51 ` Tom Gillespie
2021-04-04 16:06 ` Maxim Nikulin
2021-04-23 1:45 ` Shironeko
2021-04-23 7:54 ` tomas
2021-04-03 12:43 ` tomas
2021-04-03 12:47 ` Shironeko
2021-04-03 13:20 ` Shironeko
2021-04-02 23:37 ` Tim Cross
2021-04-03 0:31 ` Samuel Wales
2021-04-03 0:43 ` Shironeko
2021-04-03 0:53 ` Samuel Wales [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-03-31 2:23 Shironeko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJcAo8v-S4Gdaq25yVZCS186J-R+ACsrfX8S8yuS0HyDf439VQ@mail.gmail.com \
--to=samologist@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=shironeko@tesaguri.club \
--cc=theophilusx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.