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 PABuH13A1GNdOwAAbAwnHQ (envelope-from ) for ; Sat, 28 Jan 2023 07:27:41 +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 IJC+HV3A1GMryAAAG6o9tA (envelope-from ) for ; Sat, 28 Jan 2023 07:27:41 +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 27FEB33222 for ; Sat, 28 Jan 2023 07:27:41 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLefm-0000XQ-5i; Sat, 28 Jan 2023 01:26:46 -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 1pLefj-0000XH-9k for emacs-orgmode@gnu.org; Sat, 28 Jan 2023 01:26:44 -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 1pLefh-0001x8-5J for emacs-orgmode@gnu.org; Sat, 28 Jan 2023 01:26:42 -0500 Received: by mail-pj1-x1036.google.com with SMTP id nn18-20020a17090b38d200b0022bfb584987so6663188pjb.2 for ; Fri, 27 Jan 2023 22:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=PEpHfloGiNoQjkD6ktxSQe5Ssp97whU7+l74tkAs9S4=; b=Ex7Y0NKfK3ExnCNED6aZuK0lKf12w97yj2BjoJr8LK8Nm3LWLK1q+ZSK/RXuZ1+Io+ sDikZKgeZzbFc73jtbJWxhIsdMCFw2keH1B9Wc8OULsgAArLeTvTNQTRNP4QSm+qJmO1 xIT6Gtm6y5xo6oQFiH4pXATIz4e7LvIAsdUPdzwjvkbIsIBPdF3k5OAe8rl9sUq2Dyp1 cnN+eBXOu89+Wx6MjqD4hlwsNZ5PmXlE+hFU9GnuKWsg0+L8QYWztai6c1h++J2aPBAq 9qx5nwHTLyqpKGxLei4oD8YMj3l80Zq9hsxvI/fejJyyq1vPkXsNemiteryTCPlg968i YIiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:from:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PEpHfloGiNoQjkD6ktxSQe5Ssp97whU7+l74tkAs9S4=; b=mLv2sE9Xp+VqUwNTz77OpLQYwzCRASJOtyR0ua/ifazc3xDbjNXDXB3zy6OAE2rnVA xvV/vagc9z5kUrs11uUHOYEBUenrw6P4UrEIFVK+Tr1Xq7R42y25+Zag9+lahe/y0ZFB wfP2hP8eil+qhb8EGMLKKXXTIHzXuKCuBjRIxq//h66Geuu3u7nlMNp/JAiCYhp5rzG0 6v/dz43Q1I7uZJAPFeTgPR3LYAjuIT6TyejG59x08dYWk8G01mSAWsG/cXwiDfBn+xJm R/bW1y4hjjIkrhYKHHHEMxDUiI1gVyGF1n9dyWED9mkbzMez8/LXe+Cm78QUi2IfBr0w C7Dg== X-Gm-Message-State: AO0yUKUn1ZFg3QZtFPF4EW+hVHW0fIZBWtos1SelAqJGIEf1k8R+vdsw cqCP36P+xykXgKTCi2v0JvI= X-Google-Smtp-Source: AK7set87B3Mb/rgjzLn4WdPMP14dPFIy0ZcqjYbM3eyseqWN/vA0yosxj2jY44ch5M7GCqabfy4ztQ== X-Received: by 2002:a05:6a20:69aa:b0:b8:653a:6376 with SMTP id t42-20020a056a2069aa00b000b8653a6376mr1986184pzk.2.1674887199529; Fri, 27 Jan 2023 22:26:39 -0800 (PST) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id k131-20020a636f89000000b004cd1f1a14f6sm3156457pgc.86.2023.01.27.22.26.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Jan 2023 22:26:39 -0800 (PST) Message-ID: <4c27476c-ea91-167c-6df7-cec118f1a493@gmail.com> Date: Sat, 28 Jan 2023 13:26:35 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Content-Language: en-US To: Sterling Hooten Cc: emacs-orgmode@gnu.org From: Max Nikulin Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::1036; envelope-from=manikulin@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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674887261; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=PEpHfloGiNoQjkD6ktxSQe5Ssp97whU7+l74tkAs9S4=; b=pcoyC7L+yJX/iUEuHuG4M3kP/xKQeULVLS6uyClkfhng3O2mB2VEwftL5LCC4ZdON9odGl p2WNJIr8tq/uoLDDolJvvfw622p3E0OD17wn2smYd4hiYqXiQnQoutbFD37XQYZuPeNzV6 InlzUHHUcvAt4MbJ/wh9j8d/1QPdCOQbo2VICFJ6MyvVb+vGME7lpfe60UTmQgn2zDZmy7 Rj/PAyvvMBgCbRvLFI7Lj55KD+wU9JZN/CM0LXpPWvezFUgrUok4eu8n5SIN0CAjVpUyI4 ypPW8xhQUEZbqR85Ztf0qwNyQaS6ugpsW0+h5i5uL2HY8CAZYayCVnwBK2qOhg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=Ex7Y0NKf; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.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=1674887261; a=rsa-sha256; cv=none; b=GQm0H90lhay5Pgxh1zfaHpl2kkW1Q9IBUbIqlCYc5mFo0GrE2uOzMw7sVtTf2IIPukWEGa FWCVJE1I3j4P5VYSr+1vrBj4hXvP6Ss6ebYcnjbfR+O0Z4s+BtVQsmZ1u50NU8VT7vSn53 9ZRiyH03VCEBcfP9fjuqyE8S2jvhaSXiOoW6/Oq7l27iq6ArN2BgH2HyrR7DRqo4D25965 bleDyoDysRiDOCtFkQbraR5RgdCQblpEZXg0362yCARcyLIHU1rgL9LLpXnwfHPWhwn41n k2O2ctNKlSJTE9W9dje4IorVUbaIGojiATYK4DsZtu4EPHsH9ZMwS3/em+ieJw== Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=Ex7Y0NKf; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.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-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -0.07 X-Spam-Score: -0.07 X-Migadu-Queue-Id: 27FEB33222 X-TUID: B64lX0F3NzeN Sterling, thank you very much for the list of references. I was not aware of EDTF activity or the proposal for JavaScript. I do not mind to have better precision for timestamps. Minutes are too coarse. However I would consider with low priority. I would prefer to postpone some discussions now. At the current moment just be aware than one more person may have another opinion. Redundant fields are useful for humans, in addition, they allow to detect inconsistency. Date and time format with spaces are more friendly to humans as well. "T" hampers readability. So I feel some kind of internal conflict trying to achieve following standards, backward compatibility, and human readability simultaneously. I am unsure what is the proper solution. The following is what I consider as more serious issues: On 27/01/2023 13:06, Sterling Hooten wrote: > Duration (object) > as a quantity characterizing a time interval. These can be > written in different formats. Interval, duration, elapsed time are tricky. I do not have preferences whose definitions we should follow. Just an example: (info "(libc) Time Basics") https://www.gnu.org/software/libc/manual/html_node/Time-Basics.html Notice that 1 day does not necessary means 24 hours. Depending on starting day (e.g. before DST) other relations may be used, either 23 or 25 hours (usually). It is still 1 day. The way to specify interval should be chosen depending on application. Another case is January, 31 + 1 month. It actually may mean last day of January, so expected result may be February, 28 or 29. This case February, 28 + 1 month (the same interval) is March, 31. > Local system time > Local system time is determined by applying the system's time > zone offset and year offset values to UTC. The Time of day > system value displays the local system time. Local system time > and system time are used interchangeably. "System time" is often used in the sense of hardware clock and originated from the times when DOS or Windows required local time. > Time Zone > A place/region. Do you consider e.g. Etc/GMT-8 or UTC itself as a time zone? > Floating time > A wall time value without time zone or offset information. E.g., > 2023-01-24 or 6:45pm. A potential source of confusion with timestamp in seconds since epoch as a floating point number, see `float-time'. (info "(elisp) Time of Day") https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-of-Day.html#index-float_002dtime > Org must first support > fixed/absolute time instead of just floating time. Am I wright "in addition" is applicable here in the place of "instead"? > • Design and implement the time zone aware calendar system This is a > separate project. Will not such decision ruin "every Wednesday at 3:00 PM" at the moment of DST transition? I would vote that IANA DB should be used for calculations despite I have not seen a library with perfect API. Though libc with some tricks may allow to do most of tasks. (Even in presence of limitations such as unavailable identifier of system time zone.) This is the main point of my disagreement. If real time zones are not implemented from the beginning then the will be never supported, so the whole bunch of code will be requiring throwing away while keeping support of some formats to read old files. > • We are able to defer to experts and 35 years of knowledge rather > than debate among ourselves Experts may generate enough pain such as requirement to not support IANA timezone DB as it was in EcmaScript 5 (Chrome followed it, but in Firefox conversion between local time worked correctly).