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 EIvhMrDwzGNkAwEAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 09:15:44 +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 KIz7MbDwzGOfMgEAG6o9tA (envelope-from ) for ; Sun, 22 Jan 2023 09:15:44 +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 4A707F411 for ; Sun, 22 Jan 2023 09:15:44 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJVV5-00066a-0P; Sun, 22 Jan 2023 03:14:51 -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 1pJVV3-00066P-0K for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 03:14:49 -0500 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pJVV1-00023x-2W for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 03:14:48 -0500 Received: by mail-pl1-x630.google.com with SMTP id 5so3498175plo.3 for ; Sun, 22 Jan 2023 00:14:43 -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=PUUcamBz3Re7RkUuNXfIMKQxnabdMW0PpBWVUllRV/M=; b=T8hApP3dzGlmiZsW2sFRITav/Ka58i3UPyUBYuPKoevLv7BX+HD0JB9KYywxmNYQKv JhTCwBK5NgeTXb8UlAOVpo03v4Mbsc8wbk336fbq4DLG0VWNgjm5LVu9wz7bD+Ck4Jtr SE5pSJ+pxj/TQPev6dnptasSyNKVK5IqTofkboDGm67jp6DIgRPy9ANjk48siV0K844o 8P43qDExx4kbqD/+Mwscjc75WyfXq6jDZQjMLZHOFeMaAEDHLys6awVQI4Ljsss30rU2 LlpgvFV0NlLb1LpaDICofSi9zpfYXuGi/TbrknEO22KuXd4GAOiFc/KzeVuias1Mq5Pg 364A== 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=PUUcamBz3Re7RkUuNXfIMKQxnabdMW0PpBWVUllRV/M=; b=YNFohC9Py9U/bZgCAGYz0DiILH20efQ9L/CCqcfjHpXzpba/vFfWKDoMyZkveh3tud i1X00f9zDbddGEGg57eDM7MBh9AbL2iSPPClUoX1ydd+fF+eK/EPmVbPQtSgbQmoqfJT G4wNpEq9hET3CYIso6c5aNZ9lsi+PvVdUk0zamYh2NDBTviPjG+BcnlkN74a5ZK4eUIR iX6DfETSosdwmdWgSu0wdCc5NJALsSOdR57X/ao2R2J/NRP5KLu0THHuoXoL+a2E1OeO F10UHguA+GHM5j3vKXxZERP1nDRj7oUaJvGrZoydCafHDFFb7+q0yz2H278kTOz+u8eM zHoA== X-Gm-Message-State: AFqh2kp8S9xaJSE/CeiHtE5a8a8ctF88YGFE8KcgNUa5t2Eg5R8KEBQA tgN51jwZLCBoSnjXeVHrTB3gQsm6LiCZFA== X-Google-Smtp-Source: AMrXdXvqfDPCB9vL6Qz1VjCRi4Flg7FS62NFW1LqV9n66MP4NF2vUzaA49hJdk56uvuT3EeSchjQnA== X-Received: by 2002:a05:6a21:9101:b0:ad:db18:6d0d with SMTP id tn1-20020a056a21910100b000addb186d0dmr20610961pzb.59.1674375281966; Sun, 22 Jan 2023 00:14:41 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id q11-20020a65494b000000b0047850cecbdesm25204941pgs.69.2023.01.22.00.14.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Jan 2023 00:14:41 -0800 (PST) Message-ID: <63ccf071.650a0220.3a980.8179@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> <63cb2d0b.630a0220.f919a.6174@mx.google.com> <63cc5983.620a0220.a7d40.68f6@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: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode) Date: Sun, 22 Jan 2023 18:48:42 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::630; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x630.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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674375344; 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=PUUcamBz3Re7RkUuNXfIMKQxnabdMW0PpBWVUllRV/M=; b=mqg76dnrRNiofHoyFiDeQwpPKm6yg3KTBnxbXDMtl3+C5trO80ionicO+tqx09OH+1qgwe 6MCjHywOEOf3VraUXLF9L1sY9+2a3p+hyZn1VKEJQonlw/KfKUw0VsxvQiDjNjoj+mUNFX 5EoPcnCAoZcoG4FW/moUd09QrZ3MRG0a/Ey12IO7X7QHcamEaR0kbxCoLbw/gey4Ib4N3o zdPxboOPWStjpRnXNm9Xbd+IK6ls8vUUuz+kiZhJQ7p0J4lLn3WO+q0/A1KL0aJBp329re tnCymnUz6FUjD3NgexE6JX5zypc8TuqeJm2zN7O56TAKZtkNhNfabyLks20oKw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=T8hApP3d; 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-Seal: i=1; s=key1; d=yhetil.org; t=1674375344; a=rsa-sha256; cv=none; b=CNgVG5+4f/Y+vhS6HkaBsAL6fk0YU6Hqi0tIbg6Fo+jcShovzrtE83YbyDZhrJpkTyFM/4 uJu2rdRX9CPdH0EOzI0PDzN/OCSP3ZQX4wqCjbgcMJtsDRtQX3ODmp6PVId1YWxNIFMJ2g QRKQLRl6dvQ+HFkocHZhNf3SRsmXSPlxTZ7L50H3Gp0DzCseKnNCfC0nfbHB14ZVAHl1yc qSkEWtCgC1OPMlgw1EzMMvbonLS4JsXjEPxDFsRFcCcBPpfvDoFlY0WmjGePU4bcDzv6ol Ky4+aEyUfYQ6FYg1zCj02uZlPyOf2wQUpwxsqS1ZGgyUUECdi2AnHOXKRRGC3A== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.76 X-Spam-Score: -4.76 X-Migadu-Queue-Id: 4A707F411 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=T8hApP3d; 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-TUID: H+lpSZsM5CTi Max Nikulin writes: > On 22/01/2023 04:29, Tim Cross wrote: >> Max Nikulin writes: >>> - UTC is a recommendation for planning when participants are scattered over multiple >>> timezones. >>> - You admit that some timestamps in your files may be specified as time zone identifier + >>> local time relative to this zone. >>> - In both cases you may configure overlays to use local timezone or another one whatever >>> you currently find convenient. >>> - Time chooser offers several time zone options. >> That seems to be in-line with what I was arguing, so yes, would agree. > > Great. At this stage my goal is to convince people that local time and UTC for future > timestamps are not enough for real life use cases. Arbitrary timezone may be crucial to > arrive at proper time despite it matters in rare cases. My concern is mostly storage > format, timestamp syntax in Org files. > > On 21/01/2023 06:38, Tim Cross wrote: >>>> 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. > > Let's consider the following timestamp > > [2023-01-22 Sun 08:29@+1100] > > "@" is unimportant here, I take it from Ihor's examples. This timestamp is from the > "Date:" header of your message. It is not UTC, but in my opinion it is equally precise > (disregarding seconds) to a UTC timestamp. > > Would you prefer to have timestamps in your files in such form or as > > [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat 21:29@+00:00], etc)? > > Maybe [@1674336588] (seconds since epoch)? > It really depends on what the timestamp is for as to what my preference would be. For example, timestamp for an email message is likely best as your initial example or date with remote senders TZ. Timestamp for a log record I would probably want or one of the variants because the most common way I use those types of timestamp is in diagnosing problems and comparing revords from various locations where I don't care about the local time where the record was generated, but with when it occurred in relation to other log recores. > I consider storage format as a part of Org UI, so I believe that [2023-01-22 Sun > 08:29@+1100] with offset of the usual time zone is more convenient than [2023-01-21 Sat > 21:29@+0000]. Overlays may present your local time in both cases, but raw value with usual > offset is easier to comprehend. > I would argue that all depends on how you use the information. My org files are consumed by me (reading) and by scripts, elisp and other programs. > When a file is shared by a group of people spread across the globe, they are free to use > UTC or another fixed timezone or do not care at all concerning particular offset, it just > should present. > Guess I agree, but this is such a rare/small use case, I really don't consider it terribly relevant. While I do share data relating to projects I work on with others, I am the only one who uses org mode and I suspect I'm the only one who uses Emacs. Sharing org mode files simply isn't a use case I need to worry about and sharing timestamp data from those files is rare as well - if I do need to, they will likely be processed into some other more standard format anyway. > Postgres has a reason to insist on UTC since timestamps are stored in binary format as > microseconds since epoch. It is important for performance and there is no room to specify > offset. Org has to parse timestamps from strings anyway, so it is better to use format > more convenient for humans. > Again, depends on the use case and how you use the data. > A side note. In my opinion, *by default* timestamps should be created in local time with > no offset or timezone. There are should be some preferences to enable absolute timestamps > and a function to fix offsets or timezone identifiers for existing timestamp when the user > realizes that they become necessary (e.g. before a trip). > > So I do not see any advantages of UTC in comparison to time offset specific to particular > time zone, usually user's local one. My vote is [2023-01-22 Sun 08:29@+1100] and not > [2023-01-21 Sat 21:29@UTC] (of course, only in cases when identifiers like > Australia/Sydney do not matter) with a configuration option with timezone used fix offsets > in stored timestamps. My preference is for a timestamp syntax which lets the user select the format they want and not attempt to restrict it more than that. Provided you can specify timestamp with and without TZ information and you support full and abbreviated time zone names as well as UTC, I don't think it mattters - let the user choose what suits them best. I definitely have use cases where timestamp in UTC is the most convenient format. My default would be without time zones, but enable easy adding of timezones when needed e.g. by calling the function with C-u. The availability of configurable display overlays would be very useful, but you also need to be able to turn that off easily and you probably need an easy way to temporarily update/change the overlay format.