emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Shironeko <shironeko@tesaguri.club>
To: Tim Cross <theophilusx@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Idea for handling timezones
Date: Sat, 03 Apr 2021 08:43:47 +0800	[thread overview]
Message-ID: <1fdca9a5e7e91136d0c4b8d6a38d2ca3dbc0f7d4.camel@tesaguri.club> (raw)
In-Reply-To: <87blawgrj3.fsf@gmail.com>

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



  parent reply	other threads:[~2021-04-03  0:45 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 [this message]
2021-04-03  0:53     ` Samuel Wales
  -- 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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1fdca9a5e7e91136d0c4b8d6a38d2ca3dbc0f7d4.camel@tesaguri.club \
    --to=shironeko@tesaguri.club \
    --cc=emacs-orgmode@gnu.org \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).