From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id GCiTCZy2yWMbOwEAbAwnHQ (envelope-from ) for ; Thu, 19 Jan 2023 22:31:08 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id OI2kCZy2yWNNTgAAauVa8A (envelope-from ) for ; Thu, 19 Jan 2023 22:31: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 D0BB0280A6 for ; Thu, 19 Jan 2023 22:31:06 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIcU1-0003LB-0n; Thu, 19 Jan 2023 16:30:05 -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 1pIcTz-0003L2-2m for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 16:30:03 -0500 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pIcTv-0000GY-Ih for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 16:30:02 -0500 Received: by mail-pl1-x62d.google.com with SMTP id jl3so3531799plb.8 for ; Thu, 19 Jan 2023 13:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=ozcGrnpeYr6ApU65Om+ZLLg417mjL9g9Nc3MtyoHFGI=; b=GnH6qMe6ASUPQqh8M7VHuvh1XTGwgMMcRTXSVi/6+kSZ12zR7N7tKTDPERoC3fUe2z PxSQUyuY5+TVLCtLiAfCdUBouXkS9+Pv4UaJQaAHsndGLOGyqPbO5P9nkLIOstiHf9V5 7pKuI73uyjCZjHWAXoA/60rcdby0aM1thoRQHMi90ZPVettzA5ASKYoO6x+JF88mSXn9 rZXCigO7NNdaV8J+iy3l3ONXIfqNxI75aplTu6lJPPSAXiZrOQW8rMfWVuiaPUCO/MoG cMFP7rYVHJTv7tfwcBeaR0WjH0Fs6McBtWuaPY6Lw9KmmVnW1NyfP4R29Pqr76X7itou G4Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=ozcGrnpeYr6ApU65Om+ZLLg417mjL9g9Nc3MtyoHFGI=; b=aByMCFd6Dzx7NnxaAqK4xiqNM/NnqFQaSgq7wOZ8oibgq+zp9ezrNUV8yRkc5ryEtC 9qgwP+R++JKLawPixJXHd8Ovem+/VCdxTwggcBwCoeBLzuDhRDUY2OuSkUIdAcRplfrY gDKp9mXhvb7oX6EwvlcdtCI4EKwuMVHsubQ9a36r5bATTF7CqfBhXcJny9x5HDxLOBvs lAEf8vDHEah0Q96lxsuu3FjNBsK1PnSi5hy60xB5yh9qliMxReRUDXeK/wg+nPGzp4do hCc68HMwgQizrftl3k1cBdCeRXS9Sul+eblk050l7LI6G5Dn6Ewyv4Bm4f2xbhBuOerI JAYA== X-Gm-Message-State: AFqh2kryDQZ9AafcMiOh6SBpAVAPObn67eZyEMknOhqtDhxUFAMLhw9M 68XOM9x8cZcJ3t0nhOUHJDbwagFrACc= X-Google-Smtp-Source: AMrXdXv+itFkak22P8w2FGpH3gMTsYUE490zYnQEjvbY6yUeMo7ROc4a6vUoW40iKP3ro5F3pzniNg== X-Received: by 2002:a17:902:f149:b0:193:23b6:d23b with SMTP id d9-20020a170902f14900b0019323b6d23bmr10386577plb.16.1674163797271; Thu, 19 Jan 2023 13:29:57 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id o17-20020a170902d4d100b001948af092d0sm2182227plg.152.2023.01.19.13.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 13:29:56 -0800 (PST) Message-ID: <63c9b654.170a0220.d82d2.4254@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> User-agent: mu4e 1.9.16; emacs 29.0.60 From: Tim Cross To: Jean Louis Cc: Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Fri, 20 Jan 2023 07:09:14 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::62d; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x62d.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=1674163868; a=rsa-sha256; cv=none; b=a9U5pZW1xoD+4PqIL78A8GtHYw7kf9eX/uo4vLRFbhgL5oqhvkacDm6A+7EMLYDcMtarkn uOGdvPnHmplYfSSe5SqGW1Uqin40HZeXgCt2xIxsRJ4oFYfeLvPE6RmCZV4G60WUdxJrUr lhuN8wN9KHWsVrE3vkmtkeW/Gz7HnNHaXJDzwIAjepnwe9GAP+pI3l1B5ykcoZKamNEIsC BNeXCywSmgUCOYV8QWgO7E0tpc70O0Uv0bx0xspoO52IkQs25IruZiGWL1wWijiRJLp+Iz JEa890qp8snF3GOCjvffG2GLugue0L6hE8Y4z5ciFju3CpDyp2c1BPVbXvyI8g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GnH6qMe6; 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=1674163868; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=ozcGrnpeYr6ApU65Om+ZLLg417mjL9g9Nc3MtyoHFGI=; b=DnZ5mvG/izl8Z8cY9A7CN9acoGWFO9i5xYfkFxhzIcSTDDrfKPZayd3DguhDBQVQVIdafW 3HGsEuO4mJFiDVXbKVlKj/CaCqK4Xs9WYGOpt/K/RlV0mLIpftrJASMm4vOGgve4ayMT9y b1lrTLs3r4QP7kZIyaT23zlkvG/TxzSDQIgqfJSzKrVJ/Ld7ZdmbwPjOh1xNSlWt7jnWx3 /Q83xO1gc5u3vmJRmRAMs3DzIuJSaWPO+vvF/LxzuExEb9FgezScUci7Bf4BC6L7f2O6XO gCGbThvCBVuI95hKw79TjxamAWnunXkZsIsVaiXgi3e5/V6+oAwcT5rBJ5bBCA== X-Spam-Score: -11.59 X-Migadu-Queue-Id: D0BB0280A6 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GnH6qMe6; 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: -11.59 X-TUID: yEJ5liT8uJF0 Jean Louis writes: > * Tim Cross [2023-01-19 10:48]: >> You completely misunderstood the specific issue being discussed. You >> clearly have not been following this specific point being discussed and >> your long reply just confuses matters rather than helps. >>=20 >> This issue is in dealing with the meeting time when the local timezone >> changes due to daylight savings time and the fact you have two different >> requirements > > I do not use Org for time stamps. I am using PostgreSQL. Then your input here is not terribly relevant IMO. > My time > stamps show correctly (hopefully) as I rely on the design of that > software. I may be very wrong. Though as user I want simple thing, to > record time, and that time has to be displayed in my time zone, and I > want to have functions which will provide for example accounting > statement in the time zone of the recipient in Washington, USA. As > simple as that. > Completely irrelevant to the point being discussed. Yet again, you are just pushing your beliefs and pet peeves without actually comprehending what is being discussed.=20 > There is no need for Org to deal with daylight savings, as UTC > underlying functions are expected to deal with it. Time zone database, > C library, I cannot know. But any error there shall go to system > maker. Developing such complexity on Org level is not necessary. > Yet more indication you don't understand the issue. Nobody has suggested that org does daylight savings calculation - in fact, the one constant from all the issues raised in this thread is that all the time zone calculations, conversion between time zones, calculation/conversion to display format etc is handled by system libraries not org.=20 > For Emacs it makes fun to have various calendars, but for > international time, that has to be handled by system libraries. > >> 1. For meeting where all people are in the same timezone, a transition >> in/out of daylight savings changes nothing. The meeting time stays the s= ame >>=20 >> 2. For meetings wiht people from different time zones, when daylight >> savings transition occurs, the timestamp needs to be changed. Nothing >> needs to happen for the people in other time zones - it isn't their >> problem and their meeting time is not affected. > > Sure, but that is not calculation for higher level like Org, it is for > lower level, like system library. Discussion shall be given to > developers of GNU C library to solve calculations with daylight > savings. If such functions do not exist, then they can be made. > You still missed the point. It isn't about the calculation - where that happens is largely irrelevant and as has been stated numerous times, org will use the built-in Emacs interface to system facilities for this. The issue is far more fundamental. Display the agenda with correct meeting times regardless of daylight savings transitions. As only meeting with participants from different timezones are affected by such transitions, we need a way to distinguish those timestamps from timestamps for meetings with all participants in the same time zone. >> Ihor['s suggested solution was to just use the TZ of the 'meeting', but >> that is ambiguous. A meeting doesn't have a time zone and picking just >> one of the recipients doens't help as now you just have the issues of >> their daylight savings transitions etc. > > =E2=98=BA=EF=B8=8F A meeting can have time zone. My friend, that is exact= ly how we do > meetings, I have even given examples from my life on meeting > scheduling on this mailing list.=20 > Nobody said meetings cannot have time zones. Again, work on your comprehension. It seems you skim read then jump to the wrong conclusion. A meeting does NOT have a time zone. Participants in the meeting have time zones and it is possible that every participant in the meeting is in a different time zone. The meeting itself has no time zone. > >> The 'solution' is to record this meeting in UTC tz. However, to make >> this 'workable' for most people, the interface for managing timestamps >> needs to make this easy. > > Then again you have to tell that it is "UTC", which means you are > already specifying some time zone. hence the bit where I said=20 "However, to make this 'workable' for most people, the interface for managing timestamps needs to make this easy." > > You could tell that Org always thinks of UTC, but that again means UTC > as mark, must be somewhere placed, all users must know that it is UTC, > and again there is need for users to display time in their time zone. > > What do you achieve by that design?=20 > It achieves exactly the flexibility needed. As has been made clear many many times in this thread, what we are talking about is the ability to add time zone information, not a requirement to do so. If your use case needs that, then org becomes more useful. If it is of no benefit in your case, then you don't have to use it. To reiterate for the last time, there are 2 clear and different use cases for timestamps associated with meetings. 1. A meeting timestamp for a meeting where all the participants are in the same time zone. This meeting should remain at the same time regardless of transitions in/out of daylight savings. The meeting is at 3pm every tuesday all year round. 2. A meeting timestamp for a meeting where all the participants are in different time zones. When daylight savings transitions occur, the time of that meeting needs to move forward/back by one hour (depending on which transition occurs), but only forthe local participant. Nothing changes for the other participants and they do not need to know that the local participants meeting time has changed. The original question I posed is how would org distinguish between these two timestamps and know that the second one needs to have the time changed following a daylight savings transition and the first one does not.= =20 The answer is to use a timestamp in UTC timesone for the second meeting. Note that this doesn't mean it is displayed to the user in UTC time - it would be displayed to the user in their local time. For org, this means everything would now work. When the user's time zone transitions in/out of daylight savings time, timestamps with no timezone data or in the local time zone say the same. TImestamps in UTC will display an hour earlier/later depending on the transition and the person will still turn up to the meeting at the correct time.=20 > You will get confusion, as you are forcing majority of the world first > to understand what is UTC. > That is an assumption on your part. If you had read and comprehended the thread, you would have seen that once we identified that using the different timestamp time zones could address the two use cases, the next question was about how to implement this to make it easy for the user. For example, we could have functions specifically for booking meetings with participants from different time zones or we could have a different interface for booking meetings which gets additional details from the user (such as the list of participants and their time zones) or any number of other options which make this easy for the user and hides this detail from them completely. > Computers don't do that, they ask you, where are you? Athens, Greece? > Thanks, here is your time. > > They don't tell you "let us keep meeting time in UTC" confusing users. > > Follow the decade long trend human usability trend and use time zones. > UTC is a time zone - just one where offset is +0000 >> For example, I would probablyh want an interface where by default, >> my timestamps have no TZ data, but if I call the command to add a >> timestamp with the universal argument, it will add a default tz and >> allow me to easily change it to a different one. > > Time stamp does not need to have TZ data, and your function desire is > just fine and correct. > No, as already explained, without TZ data, there is no way org can distinguish the two different use cases outlined. There have been numerous examples where TZ data in timestamps will be extremely useful. What now needs to be clarified is - Best interface for managing timestamps with TZ data - Best way to deal with timestamps with tz data and export backends (for - example, your workflow where you want exported documents to have the timestamps in the local time of your clients) - Strategy for dealing with timestamps that may have different time zones when it comes to calculations such as duration, repeating etc,=20=20 plus other things not yet thought of or discovered. This will be an on-going refinement process that will expand functionality/options. Precisely how it will evolve is not 100% clear at this point. That will be determined by how people use it and future feature requests.