From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id iKdqBoAcxmOxaAEAbAwnHQ (envelope-from ) for ; Tue, 17 Jan 2023 04:56:48 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id APNvBoAcxmM9DQEA9RJhRA (envelope-from ) for ; Tue, 17 Jan 2023 04:56:48 +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 B779A1BDE9 for ; Tue, 17 Jan 2023 04:56:47 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHd4c-0008BQ-Rq; Mon, 16 Jan 2023 22:55:46 -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 1pHd4Z-00089X-SQ for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 22:55:43 -0500 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHd4W-0005YW-Qc for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 22:55:43 -0500 Received: by mail-wm1-x334.google.com with SMTP id j34-20020a05600c1c2200b003da1b054057so9167481wms.5 for ; Mon, 16 Jan 2023 19:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakatara.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=naR+bcVQZezNQuFSlallVKrJ/+KGP1q1stm4FVVoy6o=; b=LceHP+YZd7Ctw/bWT7hJJoL80CD+Hsq/9wPeqcGuWiXrTkQDyras4PdfUui2ihIguW Gi6IYwqTrmLeJnWuwFbydrITwHztVcCJ7YIolCWUSYJPgOgMUGLyMjdLH9ez/xVqqDvP OC86CE0zUAO3qtKvnnDJD5FLYbLj8CJs0fxgyUKwKuA+cyZawVF3Yp/uNrxGK+R5Ev2r WvOsgW5yJaYEjT5bzEULsub6rCkX730Qj2+5s1IhluZlD55zB0alaXr+aCT7CSj3OVUk bjKsrpdI0HtSHVPaRgLnlYGnEue317ey4qiB+x7QcYUDQBsuPROCN0zQnmyw0jqoVL/E +jMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=naR+bcVQZezNQuFSlallVKrJ/+KGP1q1stm4FVVoy6o=; b=mfRYWGLckv9/ND6cR3b24BKdyUe4Wj7Eq/VtbFFUV5e357NSeWsTC+QbCBnH0ynDux Fnw4AgJREiRL3bs7lFBbNToV3Xn0xbE/xeummfHEzoNXPq63ietNkNx8wBbcq171iwfZ XSsoQLm5F0NfCv9PtJhQAMpKr1lpUsXVCLnDKyhitCl+sMNRxgm+UjL60XK5GZv787lp c5vlqnqiG3f0eVRrcuFZXVRlSDolUXii5fGZiCPKbKRd17/EH6ZD6WzmjFmBsP+uujUW rzLxXSoNsgQh3DsXcuPwJ5gnnRqv+gcW1wOU0drPL/UkfL5N7bgxpPItntDAZRx48OJo ccPA== X-Gm-Message-State: AFqh2koNM8aUJeS5mPGSlEDCkVap4x6pWzHbaBQjYLrABETcrZwBGTSP cvDUpXV14lGvUjaP7Xp37caLclZOlrbib8xGwrS4SdfIRDe7r8oc X-Google-Smtp-Source: AMrXdXu1ip2n/8UTs8ThD3gZcX3A8IC4k0W7xheEiKTg9cd3FnBoF9W7mwhEbSKVNzmeNDopKe7sUKSZYuxJRSrqSmk= X-Received: by 2002:a05:600c:212:b0:3da:74c:2ef5 with SMTP id 18-20020a05600c021200b003da074c2ef5mr87713wmi.113.1673927737639; Mon, 16 Jan 2023 19:55:37 -0800 (PST) MIME-Version: 1.0 References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> <63c2aa9e.170a0220.3bb49.9ef4@mx.google.com> <87pmbhz1x6.fsf@localhost> <87wn5mlo7f.fsf@localhost> <87pmbelnd0.fsf@localhost> <87fscajo2q.fsf@localhost> <87cz7ejmgu.fsf@localhost> In-Reply-To: From: Daryl Manning Date: Tue, 17 Jan 2023 10:55:01 +0700 Message-ID: Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda To: emacs-orgmode@gnu.org Cc: rjhorn@alum.mit.edu Content-Type: multipart/alternative; boundary="0000000000002e9b9705f26dacf4" Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=daryl@wakatara.com; helo=mail-wm1-x334.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, HTML_MESSAGE=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-Seal: i=1; s=key1; d=yhetil.org; t=1673927807; a=rsa-sha256; cv=none; b=aA/+ZgM5bltEj8H26hg4ItnpdH61yL5niMfLIHnsa56dVnogyKksxTMJDlg0tVZDPzhdkO cZD8WlcvjKz3fUeZCXXziZBFR7gKrpx+5f1k3BfTmdvr0KNnG6kijxybg5K1eef5Ae0GHw YANp/QpdM0e6kgmp/DWe0klPLA9BbgmPCf79AIkTFgxW9JlYf0UbgeLjrWCfa7z6P3a6Q6 MBITDp7vLoXaweCDFxEEySxDDpFrkzsZZWo/2gd8K1ddEwRxwILK6Ly8BFecvC8UiT504v oJRbMRQfhFXb2hiXkVLfnXLxwK9iz7RdGfeuMzrOtfVMX/hKsKBZUDW9pAuqxQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=LceHP+YZ; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673927807; 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=naR+bcVQZezNQuFSlallVKrJ/+KGP1q1stm4FVVoy6o=; b=dEJ5GFGX4hM5am9hlQjoTTRbMFmTOgZm4evV2iIL073Kcbien4jQExI4WlGec1YUV6whbE LGr+Aq1qNMcwJ05hbi910DZGia9OxiOePSsSBy+1yk0vbj1h+R/0DUSyHtJDDBy6HPWbDb Nsa05sN0q/ArmytIzUDrTYMBYcqN8aYqqjrW7+10RBP/RHnal9QD/RnwzChQMrRZ9D6ZjH oHzIHOzr1OFRc6KEkjZ7eDiDnvc4qC36nEn1k9j+aAM9jBgiQt9HFmn8s8fYW7yhlA/aKq hr/QXwFsJ5cgoSVn6ZstnY1dp6DOCYSuTyMIb25460xnFl2jVSDcyM2gEYy75Q== X-Migadu-Spam-Score: -4.03 X-Spam-Score: -4.03 X-Migadu-Queue-Id: B779A1BDE9 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=LceHP+YZ; 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=none X-TUID: FADjKTC7hdiw --0000000000002e9b9705f26dacf4 Content-Type: text/plain; charset="UTF-8" I'd argue that setting a specific datestamp and time for DST would mean that you expected to meet at that specific time and date as per DST. If the clocks changed you'd be out of luck (that's where I'd argue you'd use a non-specified timezone for a meeting that re-occurs at 10:05 regardless of say PDT or PST). But if this was an issue with a recurring meeting, then when the clocks changed someone would be out an hour because they had specifically booked with DST in mind (note: this is more useful than you think - being in non-DST countries and having scheduled meetings in DST based countries, a lot of cal applications get this wrong when what I actually want is for that DST scheduled meeting to now be reflected in my calendar on the fact they've switched to ST in their time zone - so shifted an hour.). But I feel this is something that would be for people who need to take advantage of this. And, more often than not, is a recurring meeting issue when DST/ST changes occur. Daryl. On Tue, Jan 17, 2023 at 3:54 AM Robert Horn wrote: > > Ihor Radchenko writes: > > > Robert Horn writes: > > > >>> 1. Time (YYYY-MM-DD HH:MM) not continuous and may change arbitrarily at > >>> certain times a year or in future or in the past: > >>> - DST transitions are not stable and change from year to year > >>> according to strange rules that may involve Julian dates or > >>> counting weekdays > >>> - DST transition rules may change over time > >>> - The new year day itself is not necessarily fixed (England > >>> - Julian/Gregorian transitions happened at different times in > >>> different countries > >> > >> Note that as a result "time when it happened" has different rules than > >> "future time when it is scheduled". There are lots of other times that > are > >> scheduled as "future local time, subject to changing DST rules". This > >> is particularly tricky for repeating times for regularly scheduled > events. > > > > Not really. Countries may change DST at any moment in future. Or decide > > to switch calendars (consider countries near the day transition line). > > > > And "past local time, according to the DST rules in effect at the time" > > is also an option that might be useful in certain scenarios. > > > > The issue is clarity of the expected rules for the format. If I > schedule a meeting for 10:05 DST, but the rules change so that it is not > DST at that location at that time in the future, what is the expected > interpretation? It could be: > > a) the meeting should be at 10:05 ST, because the intent was to meet at > 10AM in the then local time. > > b) the meeting should be at 11:05 ST, because the time was chosen to > correspond to a particular sun angle. > > Getting the rules and explanation clear is the issue. It's a mistake > that a great many people make with scheduling meetings. Those two > behaviors need different encodings because they behave differently. > > -- > Robert Horn > rjhorn@alum.mit.edu > --0000000000002e9b9705f26dacf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd argue that setting a specific datestamp=C2=A0= and time for DST would mean that you expected to meet at that specific tim= e and date as per DST. If the clocks changed you'd be out of luck (that= 's where I'd argue you'd use a non-specified timezone for a mee= ting that re-occurs at 10:05 regardless of say PDT or PST).
<= br>
But if this was an issue with a recurring meeting, then when = the clocks changed someone would be out an hour because they had specifical= ly booked with DST in mind (note: this is more useful than you think - bein= g in non-DST countries and having scheduled meetings in DST based countries= , a lot of cal applications get this wrong when what I actually want is for= that DST scheduled meeting to now be reflected in my calendar on the fact = they've switched to ST in their time zone - so shifted an hour.).
<= /div>

But I feel this is something that would be for peo= ple who need to take advantage of this. And, more often than not, is a recu= rring meeting issue when DST/ST changes occur.

Daryl.


On Tue, Jan 17, 2023 at 3:54 AM Robert Horn &= lt;rjhorn@panix.com> wrote:
<= /div>

Ihor Radchenko <yantar92@posteo.net> writes:

> Robert Horn <= rjhorn@panix.com> writes:
>
>>> 1. Time (YYYY-MM-DD HH:MM) not continuous and may change arbit= rarily at
>>>=C2=A0 =C2=A0 certain times a year or in future or in the past:=
>>>=C2=A0 =C2=A0 - DST transitions are not stable and change from = year to year
>>>=C2=A0 =C2=A0 =C2=A0 according to strange rules that may involv= e Julian dates or
>>>=C2=A0 =C2=A0 =C2=A0 counting weekdays
>>>=C2=A0 =C2=A0 - DST transition rules may change over time
>>>=C2=A0 =C2=A0 - The new year day itself is not necessarily fixe= d (England
>>>=C2=A0 =C2=A0 - Julian/Gregorian transitions happened at differ= ent times in
>>>=C2=A0 =C2=A0 =C2=A0 different countries
>>
>> Note that as a result "time when it happened" has differ= ent rules than
>> "future time when it is scheduled".=C2=A0 There are lots= of other times that are
>> scheduled as "future local time, subject to changing DST rule= s".=C2=A0 This
>> is particularly tricky for repeating times for regularly scheduled= events.
>
> Not really. Countries may change DST at any moment in future. Or decid= e
> to switch calendars (consider countries near the day transition line).=
>
> And "past local time, according to the DST rules in effect at the= time"
> is also an option that might be useful in certain scenarios.
>

The issue is clarity of the expected rules for the format.=C2=A0 If I
schedule a meeting for 10:05 DST, but the rules change so that it is not DST at that location at that time in the future, what is the expected
interpretation?=C2=A0 It could be:

=C2=A0a) the meeting should be at 10:05 ST, because the intent was to meet = at
=C2=A010AM in the then local time.

=C2=A0b) the meeting should be at 11:05 ST, because the time was chosen to<= br> =C2=A0correspond to a particular sun angle.

Getting the rules and explanation clear is the issue.=C2=A0 It's a mist= ake
that a great many people make with scheduling meetings.=C2=A0 Those two
behaviors need different encodings because they behave differently.

--
Robert Horn
rjhorn@alum.mit.ed= u
--0000000000002e9b9705f26dacf4--