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 WKHFE+14yWOXiQAAbAwnHQ (envelope-from ) for ; Thu, 19 Jan 2023 18:07:57 +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 EFTFEu14yWPUVwEAG6o9tA (envelope-from ) for ; Thu, 19 Jan 2023 18:07:57 +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 05C62A1BE for ; Thu, 19 Jan 2023 18:07:56 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIYNo-0006mi-5v; Thu, 19 Jan 2023 12:07:24 -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 1pIYNI-0006Zr-4z for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 12:06:57 -0500 Received: from mailbackend.panix.com ([166.84.1.89]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIYNF-0003bS-T3 for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 12:06:51 -0500 Received: from quad (panix2.panix.com [166.84.1.2]) by mailbackend.panix.com (Postfix) with ESMTPS id 4NyTYy1DD3zQXx; Thu, 19 Jan 2023 12:06:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1674148006; bh=LQG4y6th0KBvOeqtVQK5MczlLQmc577yLBcL8Dw8mU0=; h=References:From:To:Cc:Subject:Date:Reply-To:In-reply-to; b=mndKeB+MIuoPOtYy+QGpnHN8qH5v8JOMCkAxJf3Dg/NB47Zdn2Oi7Hi5m/3pT2rdk miio4mesmq6wSrYJXMJdIP9rPWhfZohCXvE21QO2HBY19iOgvZkJVHhlTYIkCi+5wK 4uIZtjZ7gizBqmEfghz6qub8eLfaYDQGVMhdJCB4= 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> <874jspk0rr.fsf@localhost> User-agent: mu4e 1.8.1; emacs 28.1 From: Robert Horn To: Ihor Radchenko Cc: rjhorn@alum.mit.edu, Daryl Manning , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Thu, 19 Jan 2023 11:56:26 -0500 In-reply-to: <874jspk0rr.fsf@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=166.84.1.89; envelope-from=rjhorn@panix.com; helo=mailbackend.panix.com X-Spam_score_int: 0 X-Spam_score: -0.0 X-Spam_bar: / X-Spam_report: (-0.0 / 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_FORGED_REPLYTO=2.095, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: , Reply-To: rjhorniii@gmail.com 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674148077; h=from:from:sender:sender:reply-to: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=0jG0k7LKqr5u4bR0oh6d+aM/pzr02BHeTC3SRZZmM2E=; b=udgo/BhXdOIT7+PCKU5XiXr1Eo8J3ufPOC/nm+yiG9eYU0gOcNCkxek2zx/gVKBzKdSVjn IHTIS1IASejsbj3Q0y7Xxdu4atY098IYTGXtHWrgVJvebOgz5lrVyDkuCQgqy0/kczj3Hd /boR7cyjw5uVxSz8ZN/Y1o7B143WY1aY5I8wtivxdISVBlxggcXBaodzh0HLoiLu6cZ1A2 oTn5FX7qJJUysUGfWUseucfZJXb0+95tvcuCp0XMjISEpY1CAuGEFSiN2lf9DIIDUqfugQ jsG1HOMGS8JBX8GdXDfVpn7RjgrYSzEBFcGsM0FnHHmgwI+3s2WCc/90oyH0Dw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=panix.com header.s=panix header.b=mndKeB+M; dmarc=fail reason="SPF not aligned (relaxed)" header.from=panix.com (policy=none); 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-Seal: i=1; s=key1; d=yhetil.org; t=1674148077; a=rsa-sha256; cv=none; b=OU+KLcnYOEicqCC0vfoeGDGq+FnOQBo70YL0L6H6oflC0yMHM2oqD8Us7k5sVNaxNNcDI2 +YEReT2UPRAgVkznF48jRI/HfRWfC1dItRaMsVYCD8WWQN1bFs8qbFD9NSOcPJUum3Bg+5 +Pdles5DJybnytulgOGh8JdMHpgW5QO/0SJAliMm+GmCd7I9FpT4J663XZVvprHs2z8lzH 8xckpznblNGDAKajCw0YVL0ZRc64J1deHYwr7hrbqq2mC5okedObL7s7Cc39T2F7treL3q ERFP8n+bEQ/hwwcQNQjXBZkhmueHo80PSGFQXuLj7pxb3sird6LJp1rzADC1UA== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 6.07 X-Spam-Score: 6.07 X-Migadu-Queue-Id: 05C62A1BE Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=panix.com header.s=panix header.b=mndKeB+M; dmarc=fail reason="SPF not aligned (relaxed)" header.from=panix.com (policy=none); 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-TUID: klWPdORRUObA Ihor Radchenko writes: > Robert Horn writes: > >>> 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: > > Let me clarify. I do not think that we need to offer selecting DST/no > DST in the timestamp. Instead, we offer something like > <2028-12-11 18:00@Europe/Berlin>, specifying local time, including > possible DST transitions or any other political decisions the country > might make regarding the local time rules. > That would cover it for me. So, 18:00@Europe/Berlin is the "then local time", 18:00@CET would be Central European standard time and 18:00@CEST would be Central European Summer Time. 18:00@UTC would be 19:00@CET and 18:00@CEST. I've found that by far the most common scheduling uses the "then local time" because that's what people usually want. I know when someone schedules a meeting in late March they rarely figure out whether it will be summer time or standard time. > Or, if the preference is specifying time in such a way that it is > unaffected by the local time rules (for example, "+10000 hours from now, > no matter what the DST/no DST or whatever rules will happen in the > middle"), one can use explicit UTC offsets like <2028-12-11 > 18:00@UTC+02> Interesting question. Some uses (like scheduling physical process) want +4 hours to mean 4 hours later regardless of leap seconds or summer time changes. But most people scheduling issues where they say "in 24 hours" they actually mean +24 in local time. At the transition to or from summer time the phrase "within 24 hours" usually means 24 hours except on the transition days when it's 23 or 25 hours. Don't worry about TAI. People who are working in TAI are unlikely to expect org to support TAI. -- Robert Horn rjhorniii@gmail.com