From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 8IlzHJ8Ww2OazQAAbAwnHQ (envelope-from ) for ; Sat, 14 Jan 2023 21:54:55 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id KMh1HJ8Ww2OgBAAA9RJhRA (envelope-from ) for ; Sat, 14 Jan 2023 21:54:55 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 25C3E3EE97 for ; Sat, 14 Jan 2023 21:54:54 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGnXN-0002U8-3s; Sat, 14 Jan 2023 15:54:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGnXL-0002Tz-6P for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 15:53:59 -0500 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGnXJ-0006I1-CL for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 15:53:58 -0500 Received: by mail-pl1-x633.google.com with SMTP id d9so26687357pll.9 for ; Sat, 14 Jan 2023 12:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:from:to:cc:subject:date:message-id:reply-to; bh=27CkcmQyXJI2DRlRXkbh/ECdT/ofCjbOaLempY+UEHc=; b=EonAxNBtliSb46JNyT+tMuOfV/avTBmCoroesMF/pbrG8r5ITASSYxUM97/J63WJ9o 4b0lCmriJ3qkOtZtNcXElaSYnstk81hFHKHD7yVimR2BvAr5CatXDTXwBXczkgNBk1Fp ek/PJfDbO8RT8tVaYwH5Xbbkuv6iqiVcblaGtIzIaYBn65PGFSzNs4Rr2BlJuYPDjMUy Tarw+IlIpgzM0QsEOAo6B76ZFhwWvIY6HSi6S1pP0BJM6S5STsWzQsnFz+kYpOfrgIzK p1pqaoldTPiR0ZGN9Jwz97FB1v45DyVUjWnn9aHP2dEKE9hXDzVlbBwdIOcgpcrhpSu/ T/eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=27CkcmQyXJI2DRlRXkbh/ECdT/ofCjbOaLempY+UEHc=; b=MQWw/XFG0cd2COAWHI5VCf6ehxVS+lLOpPFUIKrHVeyIrzP6vPcEPr9s5DPy2GluZ9 JGdzB1W958IoSkedMvvgmfzZkQCTrcXQRqlHamYotpWjB4lyVJVdiSJ3VN7ShkbLJv9p 2KFKRtYjFd7VkYRUo29/18i/jVqX35eVKaZDEN6uqUvf/CjyCoE2U27c/1YtPc8uFhH3 1YX9gz3xYvXnvy6IlId5/1Xt95uGAzZiGxkMF6u0OIoeLta1vbLf12oiz6Bw40yzKj0j rf/WhS7l9OgnV7SZZ0hfcnxVqrwHw8ITkPvlvQLQ+i0SN1N05eYLYDFITEscQuNUa2KJ OwpQ== X-Gm-Message-State: AFqh2kpDcwm+JpcRu5+aTnhCOVKMFKRK+SxTEPDHWN/za+nWcIMikzBx YAOEgHDTKRbF++Kk/P/NdK5PyNkxx28= X-Google-Smtp-Source: AMrXdXs+6QuuUQ+NRyht8clGLriZoBl7McGxP89aa3IEecLgmNo+95Z/6Mlc7OQOJo6/5sJ/PBnyaw== X-Received: by 2002:a05:6a20:b925:b0:9d:efbf:8156 with SMTP id fe37-20020a056a20b92500b0009defbf8156mr16256064pzb.31.1673729635600; Sat, 14 Jan 2023 12:53:55 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id q6-20020aa79606000000b005813f365afcsm6417297pfg.189.2023.01.14.12.53.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Jan 2023 12:53:55 -0800 (PST) Message-ID: <63c31663.a70a0220.3ab1f.a9e2@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <63c287ca.a70a0220.4bd14.873b@mx.google.com> <63c2b760.170a0220.56455.a114@mx.google.com> User-agent: mu4e 1.9.12; emacs 29.0.60 From: Tim Cross To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 15 Jan 2023 07:30:53 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::633; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x633.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=EonAxNBt; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673729694; a=rsa-sha256; cv=none; b=cuZzehT7XS+x1xQ8TQB5Ax596BMzcq6g5cynPOsr7FYYyFG9yw6vzWFeYaBw9cboLUK310 kE3VrKS5AvvDNeoaELHrS44r6a9BTsOZedNK2vPe6oZ97V3uKTZKXeIB1qy3Cux7zXnB/b ywSNhagrRn7kv+iY5PAfMR98+2uwbN3ZzL5xHMpMw0oesRESiQSe7P+2PJ7LVX+LnceIpF P0HGpasOWLHsoknBOG1Jm6e/iazHBUszB3kKOX6I4WvWDaLK/DkM4tLZv9VQrZcteKS5+N REhoXGA1UNF9JjAtXRLK7n6eIn6TqqdmCdf03+/bK29HbCT/poWyOkVxm/UA3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673729694; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=27CkcmQyXJI2DRlRXkbh/ECdT/ofCjbOaLempY+UEHc=; b=Gdav0aZ3xPZVJH5gfFp2QArUl4SBQR/AnT2GThRuFO6JzghlUsq4BmBNw2w3UKCObH8PsG NJhu/RlkcFbdnhM41fd1/MXcKm1uTd3HJ7Yv37B0y4Su72mkzXh6nZpOn9+FUWnKYA7CwB 3oSBBW+UpCxTYcZZlYsEZWcpvBwH2thsNH5KedGtNaJT7VjwhfvAOl48ljD6agvCrPeQ1f 5ofdl3mjRTPjZuFGtVTfITqwcIVpjnuA2wc+bXWcAX+mqwgKhQwgQ3c1QNq48yWT2KsNpy g3GCWLt7Ca75GnoAw3GGZNqfhGJyz5lyPbv3ImpbM9AFXpISXBNFO953a+SD4w== X-Migadu-Queue-Id: 25C3E3EE97 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=EonAxNBt; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com X-Migadu-Spam-Score: -7.56 X-Spam-Score: -7.56 X-TUID: EERE8t306vHI Max Nikulin writes: > On 14/01/2023 20:50, Tim Cross wrote: >> I"m sorry, but I don't follow. The UTC time is the only time whihc is >> not affected by daylight savings transitions, so is the only stable >> metric. All the others are relative to that time but can change based on >> things like changes in DST transition dates/times. When DST transitions >> occur, time is lost/gained wrt the local time, but real time and UTC >> time do not change. So when DST starts here at 2am on the llth it is 5pm >> on the 10th UTC. At 2am locally, we jump to 3am, losing an hour, but the >> UTC time is still 5pm. The meeting I had scheduled for 10am with friends >> form the US was at 0:00 UTC. It is now at 11am local time, but still at >> 0:00 UTC, however, I will likely fall asleep in it because instead of my >> normal 7 hours sleep, I only got six despite going to be and getting up >> at the same time. > > Future events may be affected by changes in timezones happened after scheduling them. UTC > timestamps becomes incorrect in such cases. > > Let's assume that a company from Sydney has a weekly meeting on Mondays at 15:00 *local* > time. Their standard time offset is +10:00 > > TZ="Australia/Sydney" date --date '2023-07-15 15:00' '+%F %a %T %Z %z' > 2023-07-15 Sat 15:00:00 AEST +1000 > > They decided to invite a person from Singapore (no DST) to join the meeting online next > year on 2024-01-15 during the period of summer (daylight saving) time (+11:00 offset) in > Australia: > > TZ="Australia/Sydney" date --date '2024-01-15 15:00' '+%F %a %T %Z %z' > 2024-01-15 Mon 15:00:00 AEDT +1100 > > The person in Singapore should schedule the event at > > LANG=C TZ=Asia/Singapore date --date 'TZ="Australia/Sydney" 2024-01-15 15:00' '+%F %a %T > %Z %z' > 2024-01-15 Mon 12:00:00 +08 +0800 > > the same moment as UTC timestamp > > date --utc --date 'TZ="Australia/Sydney" 2024-01-15 15:00' '+%F %a %T %Z %z' > 2024-01-15 Mon 04:00:00 UTC +0000 > > If Australia were decided to cancel daylight saving time transition then for the Singapore > partner the meeting would be shifted by 1 hour to > > LANG=C TZ=Asia/Singapore date --date '2024-01-15 15:00 +1000' '+%F %a %T %Z %z' > 2024-01-15 Mon 13:00:00 +08 +0800 > > LANG=C date --utc --date '2024-01-15 15:00 +1000' '+%F %a %T %Z %z' > 2024-01-15 Mon 05:00:00 UTC +0000 > > If the guest from Singapore or some guy from Australia decided to store the appointment in > UTC, not as local time, they would expect beginning of the meeting at 14:00 (Sydney time) > instead of 15:00. > > The primary data for this event is > > 2024-01-15 15:00 Australia/Sydney > > everything else is derived accordingly to current state of timezone database and should be > recalculated in the case of its change: > > - AEDT +1100 > - 2024-01-15 Mon 04:00:00 UTC +0000 > - 2024-01-15 Mon 12:00:00 +08 +0800 Asia/Singapore > > So future events bound to local time must be stored as local time and the corresponding > local timezone. UTC must be used for global events (e.g. an eclipse) or if the negotiation > is to fix event time in UTC. UTC is not a silver bullet for time computations, it should > be used consciously. OK, I see what your arguing now. However, I disagree on the semantics here. Really you have the exact same issue in both use cases. Only the way it is handled is different. For example, I actually do have a fortnightly meeting with people in the US and my meeting time changes due to daylight savings transition. The UTC time stays the same, but the meeting time for me changes twice per year (moving forward/backward an hour). Likewise, it changes for most of the other people in the meeting who are in various timzones except for one participant in Brisbane where they don't have daylight savings time. His meeting time is constant all year round. With your semantics, the person in Singapore is the one who has to keep changing the meeting time while for the Ausies in Sydney, it stays at 15:00 regardless. Worse yet, the Singapore participant has to chnage 4 times per year - when Singapore transitions and when Sydney does. On the other hand, the downside with my approach is that when local daylgiht savings transition occurs, all meeting times change, including those with only local participants, which isn't great either. Again, this is just some of the issues I'm concerned people are glossing over when they say it isn't too hard to add TZ support and that we can leverage off the built-in TZ facilities of Emacs and the OS. The underlying semantics and model is far mor complex and getting a workable and user friendly solution which maintains the utility of the existing timestamps is complicated and hard. The fact you can only really rely on full timezone names e.g. Australia/Sydney and not abbreviations like AEST makes it even worse as we run the risk of loosing the compact format.