emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Left Right <olegsivokon@gmail.com>
To: Nick Dokos <ndokos@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Time-zone in dates
Date: Thu, 2 Jul 2015 01:17:21 +0300	[thread overview]
Message-ID: <CAJQBtgns+FUCw+qn_r-rULA9nQutFGvKhKdVPt8Nk9x7NxiTMw@mail.gmail.com> (raw)
In-Reply-To: <87d20bj4aq.fsf@alphaville.usersys.redhat.com>

My initial case was very similar to the one Michael described in the
telepresence example, except that in my case, I need to assign shifts
to people living in different timezones. I.e. I need to make sure that
a shift assigned to someone in Illinois will end at the same time when
the shift of someone from California begins. One way of doing this is
to set all times in UTC+0, but some of us (especially myself :) live
very close to UTC+0, so I can accidentally confuse my local time with
the universal time. It would be also nicer if shifts were in the local
time of people assigned to them too.

On Wed, Jul 1, 2015 at 6:17 PM, Nick Dokos <ndokos@gmail.com> wrote:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote:
>>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>>
>>>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote:
>>>>> The only reliable way of doing that is to use UTC as the "internal"
>>>>> representation and translate to/from local time on external
>>>>> display/input *only*.  In the case of org mode, the "internal"
>>>>> representation is user-visible, so that can cause confusion and some
>>>>> head-scratching. But *any* other method is going to be a nightmare
>>>>> (damhikt).
>>>>
>>>> This may be the correct approach although I worry about losing
>>>> information by only storing UTC.  Whether this information loss is
>>>> important or not is difficult to predict.  It may be of ephemeral
>>>> importance only.
>>>
>>> In what way are you losing information?
>>
>> Sorry, should have been clear: the time zone information itself.  By
>> reducing to UTC, you lose one bit of information.  Whether that matters
>> or not in practice is not clear but I'm always uncomfortable when
>> considering data representations that lead to information loss.
>>
>> I've been trying to come up with an example that would illustrate the
>> problem but I've failed so far.
>>
>> Funnily enough, the one example I can think of that would be difficult
>> to manage with UTC is the case of not wanting to specify a time
>> zone.  Somewhat contrived but, for instance, wanting to do something
>> every morning such as brushing my teeth.  This would be, say, at 7am
>> regardless of which time zone I'm in.  If this were stored in UTC, it
>> would be at a different time depending on where I was at the time.
>>
>
> This is actually a pretty good example. This and Michael Brand's examples
> make it clear that storing (just) UTC in the file is untenable.
>
> Nick
>
>
>
>
>

      reply	other threads:[~2015-07-01 22:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26 13:40 Time-zone in dates Oleg Sivokon
2015-06-26 14:12 ` Eric S Fraga
2015-06-26 14:33   ` Left Right
2015-06-26 14:38   ` J. David Boyd
2015-06-26 15:10     ` Eric S Fraga
2015-06-26 19:20       ` Nicolas Goaziou
2015-06-26 19:57         ` francois
2015-06-26 21:48           ` Nicolas Goaziou
2015-06-29 13:17           ` Eric S Fraga
2015-06-30  1:17             ` Nick Dokos
2015-06-30  7:36               ` Eric S Fraga
2015-06-30 15:08                 ` Nick Dokos
2015-07-01  6:27                   ` Eric S Fraga
2015-07-01 10:04                     ` Michael Brand
2015-07-01 11:22                       ` Eric S Fraga
2015-07-07 17:27                         ` Russell Adams
2015-07-08 15:59                           ` Don Armstrong
2015-07-08 16:16                             ` Russell Adams
2015-07-08 16:40                               ` Eric S Fraga
2015-07-08 17:22                                 ` Titus von der Malsburg
2015-07-07 17:14                       ` Don Armstrong
2015-07-01 15:17                     ` Nick Dokos
2015-07-01 22:17                       ` Left Right [this message]

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=CAJQBtgns+FUCw+qn_r-rULA9nQutFGvKhKdVPt8Nk9x7NxiTMw@mail.gmail.com \
    --to=olegsivokon@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ndokos@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).