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 UNcMNUN742OSgAEAbAwnHQ (envelope-from ) for ; Wed, 08 Feb 2023 11:36:51 +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 yBAVNUN742N/5QAA9RJhRA (envelope-from ) for ; Wed, 08 Feb 2023 11:36:51 +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 2B54F16584 for ; Wed, 8 Feb 2023 11:36:51 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPhnt-0000uu-5N; Wed, 08 Feb 2023 05:35:53 -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 1pPhnr-0000ul-RM for emacs-orgmode@gnu.org; Wed, 08 Feb 2023 05:35:51 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPhnp-0005vQ-D3 for emacs-orgmode@gnu.org; Wed, 08 Feb 2023 05:35:51 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E5112240438 for ; Wed, 8 Feb 2023 11:35:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1675852546; bh=u8Me7Iupx8jTVKn+oD2WRRb4OeUPPcCPUToGm59Yfy4=; h=From:To:Cc:Subject:Date:From; b=F6GLWtwz2m6YGrzNs8PM5AiqhHL/UV7DyOJ5gxAcvczEOpfHEQ43rrvTpWApZ3kLG obKyBTcLzPfRVBIN2/hEXrZranr2J7pail0gqJjMBtYVj8+6tE4jdzwRIoq7fH9IK3 R7CfkXtPOv4sXIavrSkzPS995YaIgLqXdO6JbMHWhP7O+nvIjx4J0M4nl8/YqWSqHh zs2vbelxMh2cyLTfluV/a3OHKBGlyliG4C+beqW28mC/PfP7W+QLzDa6Jml4EJ5jEL GCtHRS78Jg/+sEczuXk37rdLFOn+WqdDrskwm2T4cm4m/bNf3FZ8hzyv2cY7xAj517 ic14RxU+wbb4w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PBbxW2gC3z6tmF; Wed, 8 Feb 2023 11:35:43 +0100 (CET) From: Ihor Radchenko To: Jean Louis Cc: Ypo , Org-mode Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) In-Reply-To: References: <87lelce6iu.fsf@localhost> <87357i9959.fsf@localhost> Date: Wed, 08 Feb 2023 10:36:21 +0000 Message-ID: <877cwse95m.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=F6GLWtwz; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675852611; a=rsa-sha256; cv=none; b=DarFVVYMO5B9wI3+P4UwO6B6lEe6Y6D4og+u8ObxJ0gNIzMNpYRxHoads2Lv7MvrDOkYYo OkBQKv/cPEpfb0TRm6ZaN4SgiwxJrAmwuW5CQ25axQZ/Qtxk1aTiWxvmK/lVcssGzez1CH zlg6pUf5AM9WXjNkFHFMXo8kuv2gUZyX0jovsSwouoNxJklm1pzHBImUBpqfLiw7r3OXnn JPG+AdE4apuW2O0rwN3dIFTtxV1+4MR90yNohfNTFCUY5XdycOIqVwc72+YQhtFbvqEPia XqqpgUmd2nG7gqDfBxgPYWpVYhD6d71vSG/TJX+TcvZ86MBU8RWB3+rz81n1kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675852611; 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=WWbIPhXea0wP/q/p8bc2WwWlHjLNSONzC71XkxGrJwA=; b=Ll73MbkhPGZKUFTW0OLsGPn54lQnm/GqhxU/NWksx5JMqMQkHGdUQ344F31WACEnmFLh2+ rzHoeagpWu7YsHHjtQbWICg/7E/pqKho4DBSbRkGKhVyT7jWhXDmi8RMkYFrMZVI7QRskv mhCfZXEFI/d/Huv9/ICzxsUPRMbLgyvvyyBaLKglSwzMF2Q82vIxFzuuDlXdA+CQzuR9y0 RDc2WFPs/KLx735ZZhvRw92YkC/M/TsyITEVlJQxaCNO5apHVLFW2AlcpEZppejbB/gGIK ny9DtTRFI5ktoy7gH+OFvJdTGUalMwigh5mj6SgLeA37GpvaitCpYC33oxVKxw== X-Migadu-Spam-Score: -6.06 X-Spam-Score: -6.06 X-Migadu-Queue-Id: 2B54F16584 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=F6GLWtwz; 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=posteo.net X-TUID: kGb0pzGHDMK/ Jean Louis writes: >> It means "when I scheduled this item, I expected the UTC offset at the >> time of the timestamp to be -08 and remain so. It was motivated by >> America/Vancouver time zone, but if it changes in future, I do not care >> - the scheduled time should remain at specific time point relative to >> UTC". > > I read, though sorry, I do not understand who is expected to think > that UTC offset is fixed? > > Is it Org as program? > > Or is it human? Both. The idea is to ensure exact point of time relative to UTC. For example, when you want to schedule something exactly 10024 hours in future, regardless of time zone changes. The same can be done by specifying the timestamp in UTC directly. > Another program in future, and human, must know did the organizer of > event, had in mind: I would like to remind you that timestamps are not necessarily used for meetings. And not always shared with other people. > I find such situations rather easy to solve with database: > > - I can have column like "timestamp" with UTC time or local time plus > UTC offset, and if I did not enter any other information, that UTC > offset is considered in future. Consider this column name > "timestamp". > > - I can have column "time" and when such is entered, then date is > extracted from "timestamp" column, and combined with time. In this > case UTC is only calculated in new time point but not used as period > from past to appointment time. > > - I can have time zone for the future, if I enter such in other > column, the future calculation must use that proper time zone. Sorry, I do not understand what you are trying to explain here. Would you mind showing an example? > You said "I do not care", that means you as human decide that > [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset > > But from where in such timestamp does user or program understand that? >From syntax we are now defining, XX takes priority in @XX,YY. > Maybe this way (hypothetically): > > [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] > > as that way you would give signal to program that you want UTC fixed > time in future, and not 12:00 o'clock necessary. I am sorry, but I don't understand what you mean by UTC-FIXED. >> > The UTC offset is the log what was the UTC offset at the time point >> > when timestamp was created, as future UTC offset cannot be known. >> >> Sure. -08 is expected offset. > > If you wish to specify UTC time in future, no need to specify even any > offset, but you can. > > Look here in first example how event is defined by using UTC time: > https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html It is sometimes easier to define UTC time +offset instead of doing an extra conversion in your head. >> > Making it "fixed" does not fix it in real time, you are then >> > introducing something new than what other programs do with time. >> >> I do not understand this statement. > > Well to understand that, you have to make practical examples and > understand what would human think in periods of time A, B, C, D, from > creation of appointment, through possible changes of DST, time zone, > UTC offset, to final appointment. > > Look here the second example of group-scheduled meeting that begins at > 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12, > 1998 > https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html > > DTSTART;TZID=America/New_York:19980312T083000 > DTEND;TZID=America/New_York:19980312T093000 > LOCATION:1CP Conference Room 4350 > The stuff with iCalendar works for reason that it is structured. The > timestamp such as: DTSTART:19960918T143000Z will clearly say that time > is specified in UTC time. No need for confusion with time zone. > But if DTSTART has this: TZID=America/New_York:19980312T083000 > > Then it becomes clear that it will be the UTC offset in future with > assumed mentiond time zone. > > But if you mix UTC offset, plus the time zone for future, that makes > little sense, unless you introduce some tags that timestamp is > recognizable as using UTC time, or that it uses date/time and time The problem being addressed with @+08,!Asia/Singapore is possible future change in time zone. Imagine a yearly meeting you attend at [2024-01-02 19:00 @Asia/Singapore,!+08] while living in Europe/Athens (UTC +2). Over the years, you are used to meeting being held 13:00 @Europe/Athens time, and you do not really follow Singapore government politics on time zones. Then, one year Singapore government decides to switch the time zone to UTC+7. Your TZDB will get updated, but you may still miss the meeting even though Org agenda will display the correct new local meeting time of 14:00 @Europe/Athens. It would be useful if Org could notify the users about such changes. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at