From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 yLu0NWjdx2OGRAAAbAwnHQ (envelope-from ) for ; Wed, 18 Jan 2023 12:52:08 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YG+MNWjdx2NKqwAAauVa8A (envelope-from ) for ; Wed, 18 Jan 2023 12:52:08 +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 700B41545B for ; Wed, 18 Jan 2023 12:52:08 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pI6ya-0007zj-KP; Wed, 18 Jan 2023 06:51:32 -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 1pI6yY-0007zU-EA for emacs-orgmode@gnu.org; Wed, 18 Jan 2023 06:51:30 -0500 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pI6yW-0003Eo-IQ for emacs-orgmode@gnu.org; Wed, 18 Jan 2023 06:51:30 -0500 Received: by mail-pj1-x1036.google.com with SMTP id bj3so32319390pjb.0 for ; Wed, 18 Jan 2023 03:51:27 -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=Ov0JqT5LJe9V4eOEFk7PUrxrouJVL5GJk3xtUfqidY8=; b=KNgkZZeZ8gOx5u8lPlGCnKXokREm/GGxiaHLZeEPUN1YvhICwu4JuK+LcwcZidES18 Skhkis9wjdZnv80OQvxgN4INfROm+vhfggT972xStcWjNftv+KCyuXjmsSafVhBy7SiR uoOquND3P9Z5GpDMvQicPsA7ZWoJ+gs6QgFJC/xOe4J9F+MuyMURKtJ17Yj9qXec3rJJ k4ZsrkUtkrAFTOjiQAdirFasW1WWAP52w5nT5Jjujie9E9ys2G+3Wbd2qz2cFZBwqCCH iRbPqKInsW6Biyjt4OVfIk2/kEFm6rJLvCuGA8BuJMx6JGoGGhwUZnmvLzUjpyp4OMYp tpmA== 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=Ov0JqT5LJe9V4eOEFk7PUrxrouJVL5GJk3xtUfqidY8=; b=vA1elRrXAY2SmSTXEkC6fCIgNs7Y8tBBeDtSk96whAQ11Z17nUJIjN/d7bdXUj+xne ms9pNFnlkrMOqKHpjzNbkujtt3LCxybSAKIdqDm3VBny0BClefVryMaSg21cQ1ceitQu t1efgE8Ef+oJe2tSU5fb2POFWR/yqdpasOp17lDy7QLrnnSBJ9kAUn+Py7+1ljtKyBpf BjbiB8HetC8Mr/PLfjaZMilKIJJG2gl3G8fvwyPmMBtRpu8nnE/F1dByCL92uW+kvNnY f79jNSGThyxFEHh8f6yrBjTxQgOshrTaRFCS7B75pL/iooo8KweX0vUN7/4UtMyJMnIS uaHw== X-Gm-Message-State: AFqh2kroCC5m6Eak5MwBbjOudDKaT8ADuI66FmLQBwwhea9VxraE53Uh sf+ayNjGXcsI5KkrblWqn4xw9UaY9VA= X-Google-Smtp-Source: AMrXdXvke72C4CRoiCOSz9l02+iBsvtk/r6+JoCKZsz7cIHQqLCldiKe2YWlTCfVKpazl6jwWcWuww== X-Received: by 2002:a17:902:6ac3:b0:194:c25a:d824 with SMTP id i3-20020a1709026ac300b00194c25ad824mr146794plt.26.1674042686365; Wed, 18 Jan 2023 03:51:26 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id w13-20020a170902ca0d00b001930b189b32sm10008443pld.189.2023.01.18.03.51.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 03:51:25 -0800 (PST) Message-ID: <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- 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> <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> User-agent: mu4e 1.9.16; emacs 29.0.60 From: Tim Cross To: Ihor Radchenko Cc: Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Wed, 18 Jan 2023 22:43:56 +1100 In-reply-to: <87fsc88aq9.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1036; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1036.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=1674042728; a=rsa-sha256; cv=none; b=oeGOBWCPgj2qzrKyJc/Ixy3fE0n3IT4E4RrXu/WSZdCkPsG9YX0e8vcCztPSq/yosTG61F t1drWe/f6bpmFPKIFRTHUhTmMuedcnt26mu0qQztsIEd2Z5nOC7hjZgdAgC2/ZR224105V Td5UfJW0Zv3b4nbeZ1rgLHKrmWEpVoWDsyXLgq0ICVHGypDXOehmUu1mxEBwqFMm6CxFOP OAS0/uPfziQa33zqR4IxpmgmxNsCBilAvDvQIPyFhra9BJQUSa89BNXjDycmobhO2esw5u A0rZenFNM5c2gRGDDHoUG/MESoxpyOiaOsrreRl/eFlN6eY00pjAos/17e7H5Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KNgkZZeZ; 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=1674042728; 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=Ov0JqT5LJe9V4eOEFk7PUrxrouJVL5GJk3xtUfqidY8=; b=eP6ZBFUKoEzil5gufg9slkY1qwmi2WnjYoeL3VcjBS1192I24vxbdfRS5/x8w6pxVp9wiI Q+GrzE7ac6dTK2SjNp7crb1BiOgVaJLph3iEaYyMNouI9eIaAww2juOPetLP9aWSBBxxb+ OAY+fqha9AtGq7h7GKhETwUmX93STUtn0OlUIy757ga46Xu4RsDNrZgmdV1FkKLaaIwYGj Qf3Yv5WF0kvWCOl6jWbKWA5p8zWeFW+ZYvD1TI2gABTblgtHkPKELenYHNmxskbtqFSQYU 44scGJKHr80yGUn+V0M1SAz6SI1hkvWV8fIcYzX95O4CyskN9gstsI9f4fKVgQ== X-Spam-Score: -10.29 X-Migadu-Queue-Id: 700B41545B Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KNgkZZeZ; 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.29 X-TUID: xUS2+6CnHrup Ihor Radchenko writes: > Tim Cross writes: > >>> Could you please elaborate here? >> >> I have some meetings scheduled in my org files which show up in the >> agenda. >> >> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of >> the people in that meting are in the same timezone as I'm in. When we >> transition into/out of daylight savings time, I don't want the timestamp >> to change. THe meeting will remain at 3pm. > > Specifying the timezone should be good enough. > Not specifying will put you at a risk if you travel (you default OS > timezone will likely change). > >> Meeting 2. This is also a reoccuring meeting. However, this meeting is >> with people from a number of idfferent time zones. When my timezone >> moves into or out of daylight savings time, I need the meeting time to >> be updated - moved forward/back 1 hour. > > Again, you can just specify the right timezone and let Org translate it > to local one when calculating agenda. > >> Next week, I'm travelling to a different city for work and will be in a >> different timezone. I need all my meetings to be adjusted except for >> those I've already booked that are in the timezone I willl be in while >> I'm away. > > If you don't specify the timezone for both old and new meetings, there > will be no easy way to deal with this. What you may have to do is: (1) > indicate explicit timezone for the meetings in the new place (there will > probably be less of them compared to all other meetings); (2) tell Org > to use your old time zone as default - it will make the previously > scheduled meetings without timezone info use the right time zone. > >> Finally, I have a few timestamps I use to track some projects and >> progress on various tasks as well as reports showing actual and >> estimated effort comparisons as well as managing billing/invoicing. The >> actual timestamp times are less important than the calculation of >> durations etc. When durations do cross daylight savings transition >> points, it is critical that additonal hours are not accidentally >> added/removed from the duration calculation. Mistakes here could result >> in me loosing revenue or over charging clients. > > For the past timestamps, you can either: (1) make Org put UTC offsets > when recording clock data; (2) use the idea we discussed about multiple > default time zones where you can specify different time zones at > different periods of time (before after travel). > > Does it sound good enough? No, I'm afraid not. How does org distinguish between meeting 1 and meeting 2? IN meeting one, when the timezone transitions in/out of daylight savings, nothing needs to change, but in meeting 2, when this occurs, the meeting needs to be re-sechduled so that it keeps the same offset relative to UTC. Some mechanism is needed so that the user can identify timestamps like those fo rmeeting 1 from those for meeting 2. My idea was to have meeting 1 type timestamps without TZ info and meeting 2 require fully qualified TZ info. However, while this would probably work, I don't like it because it isn't explicit and would be prone to errors. Note that the above is a real scenario - I have to deal with this type of problem frequently. The other types can, in general, be handled through judicious use of TZ settings.