From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 8F8+Jk8ty2MUsQAAbAwnHQ (envelope-from ) for ; Sat, 21 Jan 2023 01:09: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 mp10.migadu.com with LMTPS id sOBTJU8ty2NPcwEAG6o9tA (envelope-from ) for ; Sat, 21 Jan 2023 01:09: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 D3B1E3830B for ; Sat, 21 Jan 2023 01:09:48 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJ1RB-00063T-2F; Fri, 20 Jan 2023 19:08:49 -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 1pJ1R9-00063E-S9 for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 19:08:47 -0500 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pJ1R7-0003CS-RW for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 19:08:47 -0500 Received: by mail-pj1-x102c.google.com with SMTP id o13so7075423pjg.2 for ; Fri, 20 Jan 2023 16:08:45 -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=ouAzyYfqweky/G02ORq7fhjaTCcIZ5TsKVxzJXwj/u0=; b=nVY4iWJdZWvuEQhS7EF4u+K+a2ZZ6JVvoX1r6VYy+SpE8DpgJ7JmWvD4nkdN/266fx Njxig/cm5p+UGnWs7bZu8uEfvOeNq9Xl1r7H1iSMGPF0VN/8R3vXKxPngi0gtyDwpfwe QkS2yoNOuIvQryRGxOSXzRFWyxVBstbYt/ooxGqfKqBmvlXl4XBcMqQE9jwfCAuokrAQ LHPFn10+FqiMfLyaYdf7eyaAS5LAjlRF4On+gRF8jBh2heNZoo1kesREhXW/+HhpHzwj zZBv0PPrncWz788sjLFlV8nAvahBSbsd3o57YoaaEsH6sA6JsA95Fah7Z84DfW0GMZA1 CQ8Q== 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=ouAzyYfqweky/G02ORq7fhjaTCcIZ5TsKVxzJXwj/u0=; b=JL1J43hTv8P3yEFeNxwTCZj0IKga4ZPxHYyEq/Jna4YKR79iMEw8hPTW3Wz/zeSXcG tQCFvxDgPbCG9i4TxXhDj/AdLdqWT4i8YFQP6jwp4xFLiWsI8KlGESOrfJoB+v9m1kSB uZdyH0bXDiHVXRNezNMlPmdz4RifSY81BSMhr/ID0UBYoqp9wFV1mBtqvsgsQf7Q/E5m iyIyI78YJZCEh7P1Y+2FH3WLI01GyyGqWGu/rVM9v3fpmnuVb//Ca49uPJm+EQAQBtSs BBea0Xrb7iSkIsrlQql+7radRYuNqRACJ3W6T+4eUy9pQA+z/PzPKwbwVppgM4o5miKG m+Tw== X-Gm-Message-State: AFqh2krx3sOaMRnDXzAZAgOBAhr/EmXncDgpt/dYSZZEvSbzdfHONDDn K/9A5JHGrOH2gTLojVy5GPOJl5llZGY3HA== X-Google-Smtp-Source: AMrXdXtijw/Br1MLS7M7yZkLRnPCNM/7kJm8tffiaBJ40j/M3iPt/L4Kn5oChStLx/Df/sCvmZpR8Q== X-Received: by 2002:a17:903:228f:b0:194:dea2:a121 with SMTP id b15-20020a170903228f00b00194dea2a121mr6115722plh.33.1674259723988; Fri, 20 Jan 2023 16:08:43 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id g15-20020a63200f000000b004d1d89ec63fsm3634918pgg.6.2023.01.20.16.08.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jan 2023 16:08:43 -0800 (PST) Message-ID: <63cb2d0b.630a0220.f919a.6174@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87lelxk87a.fsf@tsdye.online> <63ca5101.630a0220.b2298.3363@mx.google.com> User-agent: mu4e 1.9.16; 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: Sat, 21 Jan 2023 10:38:19 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102c.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-Seal: i=1; s=key1; d=yhetil.org; t=1674259789; a=rsa-sha256; cv=none; b=pp4vwxL74i0z3gAUc2c5eVZwyGNfpEZfzC8xgnLipwY9D3Sj57AV/1X6V5o7RcbxBJ2k0x E3iBuFJB7TRHz1XOdJBJstY23yY186b0hBYnwliiCg4aj0lIcM52wvyH/Y07kILUMjuDw+ GYtVRw/WQ6Upc/yRVXGGSs74lXYIUmBkMl0BT9GPxTUrsSUwdhds32oxxf7MxyaE7RARnw Xl40b7vcEU8yFJ7+NY6DNofuKJK+68kMfKDeMKQwVzoO4/deQT8IMy8qN/IYjKkwGuCQ0j aTfNkTsTGYk3oTNhBeVbceK4c1AU45t9CMHP70C05s4JnCBvQCp+Ac1dRbNHbA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=nVY4iWJd; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674259789; 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=ouAzyYfqweky/G02ORq7fhjaTCcIZ5TsKVxzJXwj/u0=; b=cGyM0ROcTNrAv+hP3+IFFRgmAw/OHjP2k9Yo+X4htcGwRGODMqU+eKmkVj2KfUlZXPah33 QLJXuKAKu2ElFIpTz1P46FMp4BPKRMF5Z3iYh+KdpGpQI9iamKORpB96/ikw7TyfSnS8Ka W2AruOBu9ijdu9bA+Jo4mEwI9UVp701PFkRWiZeC0dLh9tMzYnrFYqIHr0JfDFMRt2kXp9 Nu49xLWPcRgLhzbK3bD+W3okUafspy9im5YH4rYdquH+plaH+W2kknZZJJSphY2r1lacR4 ez2xbpiAZXixRWz7fHApetxvEBKvbUncJaR+vup1mEqIHAlWimngy0OY8OXF5Q== X-Spam-Score: -10.07 X-Migadu-Queue-Id: D3B1E3830B Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=nVY4iWJd; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -10.07 X-TUID: zIRHxtNg4jQO Max Nikulin writes: > On 20/01/2023 15:17, Tim Cross wrote: >> So far, nobody has shown any reason why using UTC to distinguish the >> case where the times need to be adjusted and local tz when they don't >> won't work a a mechanism that can be used to allow org to handle things >> better than it does now. > > Let's try to move in small steps. UTC as storage format. > > An issue with events scheduled as local time in some particular timezone (not your current > one) and stored as UTC timestamp when IANA tzdata is updated to use new timezone offset: > > https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ > Storing UTC is not a silver bullet > > Do you think it should be ignored? I faced such issue. I now think I can see where you have become confused. I am NOT arguing that all timestamps should be stored in UTC. I am only saying that when you have a meeting which is not face to face and involves people from various time zones, the date+time for that meeting should be stored in UTC. This is the only way org will be able to ensure the meeting time (which would be converted into local time for the user) stays relative to the other participants after a daylight savings transition. The use cases here is completely different from the example outlined in that long article. Firstly, much of the complications arising in that example are due to tryhing to coordinate dates and times for multiple parties. Here we are only focusing on 1 party. Secondly, I am only proposing UTC for meetings where there is no physical location for the meeting. In the case where there is a physical location, that is a fact-to-face meeting and it should be recorded in the time zone of the location of that meeting. In most cases, that will be the user's local time zone, so for most face=to=face meetings, no explicit time zone is necessary as the local time zone will be assumed. So in summary, my argument is - Use UTC for meetings which are not face-to-face and which involve people form different time zones. - Use the time zone of the location of a meeting when the meeting is face-to-face and has a physical locaiton. - Provide an interface in org to make it easier for users to select the correct format (UTC or lcoal/meeting tz). Exactly the best way to do this is yet to be determined. It could be just a general solution which allows you to select the TZ when you call the functions with C-u or it could be something more sophisticated and specific to booking meetings which asks questions (i.e. type of record meeting wiard). - It is assumed that in most cases, timestamps will b displayed to the user in their local time zone regardless of how they are actualy recorded int he org file. I suspect where you have become confused is because you read my first post in the thread where I suggested using UTC for meetings would be sufficient. However, I revised that based on responses and then proposed only using UTC for meetings which are not face-to-face and where participants are from different time zones. It appears you have missed those posts. I would also argue UTC is good for 'traditional' timestamps which record a specific point in time and for situations where you want accurate calculations of time durations. In fact, I would argue that UTC is a good choice for a majority of time stamps, but acknowledge there are some situations, notably when scheduling an event with a physical location, where it is better to use the time zone of the location.