From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id GFrQNavQ3mMvAAAAbAwnHQ (envelope-from ) for ; Sat, 04 Feb 2023 22:39:55 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id sKvhNavQ3mNfsQAA9RJhRA (envelope-from ) for ; Sat, 04 Feb 2023 22:39: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 679EA740C for ; Sat, 4 Feb 2023 22:39:55 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOQFY-00049A-2S; Sat, 04 Feb 2023 16:39:08 -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 1pOQFW-00048T-2p for emacs-orgmode@gnu.org; Sat, 04 Feb 2023 16:39:06 -0500 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOQFU-00005e-1o for emacs-orgmode@gnu.org; Sat, 04 Feb 2023 16:39:05 -0500 Received: by mail-wr1-x433.google.com with SMTP id r27so3582522wrr.1 for ; Sat, 04 Feb 2023 13:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-language:subject:to:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=aoDo1gxlowAcjLhsJsZ6SqvqWaeWpn8Z6p1JKbsVURs=; b=VyvoWkum0oCNj9Al1FPHv/gxY46V+osUlcO/oSR1Lx/jt8P9e0rkZa6IH0NizWn0Ry Q47Ke4u8DCPt8AU8lWF3S71uFcpvylwG6ukrOJZJb1JjTm8IgAAwW6RYX44li6ma2acY NzbnfbWdiLHE4BeNE4HJqlMB9hc2E7vDJgP3l7cvzjG0ejVTRz+ktS+f4WftBd4mOC45 xJSp3PrBbi5oz1DihrRb3Biy96jd267hqInckmfxnPJyqoPER/qpvquXPzGnSrd5EwH1 N/kalTRmXm9XrJixzd9bSayBHGC+dwEAwLdvYcErxsujiujD5xtF0Cx4a7AFkvnJt3AY G2sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=from:content-language:subject:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aoDo1gxlowAcjLhsJsZ6SqvqWaeWpn8Z6p1JKbsVURs=; b=FM91tQuEW2D6c/aYabO3kUlTb2M3NtJRWqxiRU03TS+9H/+baDuQsCtJ65GjCqVZFZ vQZPFoHmn7hcZOBVh3EH76xCOVl07cjfSwAV4i8Bh56l57xIYSam3nF7DgYqUYVaRQ2I mCil/+V+F9pzV1Rj6pVb8RAp9RThGKww2a5yVuB5tNmGH4BCEfqPGhmRoJUAXoarrU7F o9whKe8w0k7zviw4IMVYynuBymFHxcw+xKepYVDJ6SurYIu3zAfUGjuP3r29cVv2Lt9A zAfUGnsFz6oPZXHAysvC/FKrcUXcxvhyrl9T69/eI8dxWXlK61Qoo2J2c82/wg4YtISn Qguw== X-Gm-Message-State: AO0yUKUVZZbliQIXnyHHEQdTU0kCbyNS/hszHPLwOhN5JnF/BNz/CpBE P6AuFp/FyIpaEa4YbLNoZXU5m3US1z8= X-Google-Smtp-Source: AK7set8vTv9NOp6emNnh84Byr2NVgR2tReDoGFxC1cU6tn14lezXvImC1XOhGY3Xu0hpEHSLtnWR4g== X-Received: by 2002:a05:6000:1561:b0:2c0:dcb7:91bc with SMTP id 1-20020a056000156100b002c0dcb791bcmr14908802wrz.46.1675546742275; Sat, 04 Feb 2023 13:39:02 -0800 (PST) Received: from [192.168.0.97] (static-244-20-26-46.ipcom.comunitel.net. [46.26.20.244]) by smtp.gmail.com with ESMTPSA id m2-20020a056000008200b002bfb7c2430bsm5158140wrx.19.2023.02.04.13.39.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Feb 2023 13:39:01 -0800 (PST) Content-Type: multipart/alternative; boundary="------------WAMSNKy0U7pH30WH6XzccrvJ" Message-ID: Date: Sat, 4 Feb 2023 22:38:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: 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) Content-Language: en-GB From: Ypo Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=ypuntot@gmail.com; helo=mail-wr1-x433.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, 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675546795; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=aoDo1gxlowAcjLhsJsZ6SqvqWaeWpn8Z6p1JKbsVURs=; b=Rz32rNhqWyADKCySiqV8Qc8ITP+6cZQrBammbvpXSYICdPdthAU/EB7G3zC97jsJDX4jyo dV3mDBJLLUg8ikIiuTrfAcG9yRBtEhZaB8XOFNx/Exno1Q1O90objS7Qb4hzvaJIWQeEyG p/lst/SeKMTqrKGtqBVa1O+3Q/a0Daxht3+D0MdP3tFG7idwbLaUaA1ngfkrKCI5rJh1q7 +VJXJPXV1DMUqHj49Nu5keYdYclRdgl5bdcyoXLCrp/ACOshoUGgvuFUQsfSK6D++pi/br 7JwnVqS91ZQVP9EQVYWmnbKtWDoijOu653Dy+bfb3qn3rYRoiEA4mg0x/0Fgqw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VyvoWkum; 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=1675546795; a=rsa-sha256; cv=none; b=dXno0UoiTX4beONEKIemhFYz0OsC661j2XYtCpGt1StZ/7noqjzIV3aPEfOyscvS6Fbi6p AsfV0SvrbMsD6QtM1KkeMq0Y+rxKZZdT48sE0UkGA2oz8mGa/BIGh7rkqPVOJcNCOL2Fao tis1qV+FzC7xjjv+bOiBguDaIeKXlNFcWIHoW/g5UhrsWf7toone69QZ32VYip6y51FntV Uj4d+0BiCRnVpt7KTLvKiwiG/2r6G7QYMlnEm3BNvcZxLy+nOqw1yPRGgvMDyOa7WVEtXg RJRnz0RQGTsjYDW7O5Wxt6zS7mPbt6d1yulgkeTADtKc8ntJjvhjdpLpZUuG6g== X-Migadu-Spam-Score: -5.28 X-Spam-Score: -5.28 X-Migadu-Queue-Id: 679EA740C Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VyvoWkum; 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-Scanner: scn1.migadu.com X-TUID: U45zlwvZ0zBy This is a multi-part message in MIME format. --------------WAMSNKy0U7pH30WH6XzccrvJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > Great link! > https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ > > "Given a local time and an offset, you can know UTC time, but you do > not know which time zone you’re in (because multiple timezones have > the same offset)." > > So, given a time zone you can know the offset (Google it, for example).. > Then, given the time zone and the local time, you can know UTC. > If orgmode gets the UTC there is not ambiguity. > > But, that would mean that the offset related to the different time > zones must be downloaded and updated from some site. > As you said before, that offset can change. For example, peninsular > Spain has the same time as Berlin, but as this doesn't make much > sense, it could change, so updates would be necessary. I have been thinking about how I would use this feature. So use cases appeared, which arose some doubts about how to use this feature, and an opinion for the Poll surged: If I wanted to assist to a "Mastering Emacs book club" meeting in America/Vancouver, while living in Spain: Doubt: Should I use local time of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 @America/Vancouver] (I don't like space before the @, for the Poll). 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00]. (Spain local time). Correct? 2. If I went on vacation to Brasília, my agenda timestamp should change to: [2024-02-04 do. 17:00]. (Brasília local time).    Doubt: How must the local time zone be updated to get that timestamp changed? 3. Back to Spain, I see that, for political reasons, Vancouver's winter time-zone changed from UTC-8 to UTC-9.    Doubt: How would my tz database be updated?    Doubt: After updating the tz database, my agenda timestamp would change automatically to  [2024-02-04 do. 22:00]. Correct? 4. For the Poll: What would be the expected behavior if we used the UTC offset?  [2024-02-04 12:00 @-08,America/Vancouver]     - We should know beforehand the DST of Vancouver, or there would be warnings. It seems more difficult for the user: maybe the "-08," should be optional?     - Case 3: After updating the tz database we would get warnings too. To correct those warnings, should the UTC offset be changed manually in the timestamp?. If there were 35 meetings in Vancouver throughout the year, to change all the UTC offsets could be non trivial for a normal user: UTC of the summer and winter would differ.       [2024-09-04 12:00 @-07,America/Vancouver] should be changed to [2024-09-04 12:00 @-08,America/Vancouver]       [2024-02-04 12:00 @-08,America/Vancouver] should be changed to [2024-02-04 12:00 @-09,America/Vancouver] --------------WAMSNKy0U7pH30WH6XzccrvJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

Great link!
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

"Given a local time and an offset, you can know UTC time, but you do not know which time zone you’re in (because multiple timezones have the same offset)."

So, given a time zone you can know the offset (Google it, for example)..
Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.

But, that would mean that the offset related to the different time zones must be downloaded and updated from some site.
As you said before, that offset can change. For example, peninsular Spain has the same time as Berlin, but as this doesn't make much sense, it could change, so updates would be necessary.
I have been thinking about how I would use this feature. So use cases appeared, which arose some doubts about how to use this feature, and an opinion for the Poll surged:

If I wanted to assist to a "Mastering Emacs book club" meeting in America/Vancouver, while living in Spain: Doubt: Should I use local time of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 @America/Vancouver] (I don't like space before the @, for the Poll).
1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00]. (Spain local time). Correct?
2. If I went on vacation to Brasília, my agenda timestamp should change to: [2024-02-04 do. 17:00]. (Brasília local time).
   Doubt: How must the local time zone be updated to get that timestamp changed?
3. Back to Spain, I see that, for political reasons, Vancouver's winter time-zone changed from UTC-8 to UTC-9.
   Doubt: How would my tz database be updated?
   Doubt: After updating the tz database, my agenda timestamp would change automatically to  [2024-02-04 do. 22:00]. Correct?
4. For the Poll: What would be the expected behavior if we used the UTC offset?  [2024-02-04 12:00 @-08,America/Vancouver]
    - We should know beforehand the DST of Vancouver, or there would be warnings. It seems more difficult for the user: maybe the "-08," should be optional?
    - Case 3: After updating the tz database we would get warnings too. To correct those warnings, should the UTC offset be changed manually in the timestamp?. If there were 35 meetings in Vancouver throughout the year, to change all the UTC offsets could be non trivial for a normal user: UTC of the summer and winter would differ.
      [2024-09-04 12:00 @-07,America/Vancouver] should be changed to [2024-09-04 12:00 @-08,America/Vancouver]
      [2024-02-04 12:00 @-08,America/Vancouver] should be changed to [2024-02-04 12:00 @-09,America/Vancouver]



--------------WAMSNKy0U7pH30WH6XzccrvJ--