| External Input | User's input | Org output | Agenda output (local time) | Org time storing |
|---------------------------------------------------------+----------------------------------+----------------------------------------+----------------------------+----------------------|
| Meeting at 09:37:54, 28 February 2023, in Foz do Iguaçu |
[2023-02-28 ma. 09:37 @UTC-3] | [2023-02-28 ma. 09:37
@UTC-3] | [2023-02-28 ma. 13:37] |
20230228T12:37:54,68 |
| Same case as above |
[2023-02-28 ma. 09:37 @timezone] | [2023-02-28 ma. 09:37
@UTC-3,timezone] | [2023-02-28 ma. 13:37] |
20230228T12:37:54,68 |
| Party at my home, tomorrow |
[2023-02-13 lu. 14:15] | [2023-02-13 lu. 14:15
@UTC+1,timezone] | [2023-02-13 lu. 14:15] |
20230213T13:15:54,68 |
- Should convert show every timestamp timezone, so we know local timezone is correct?
- Sorry for the table format, I don't know how to export it from
orgmode to thunderbird's mail editor.
* Max Nikulin <manikulin@gmail.com> [2023-02-11 07:47]: > On 10/02/2023 10:29, Jean Louis wrote: > > 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed > > UTC" > > I do not see any reason why obviously invalid timestamp draws so much > attention. > > Resolution may be rather concise: behavior is *undefined* since field values > are mutually inconsistent. Perhaps implementation may prefer to treat it as > 2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. `org-lint' > should issue a warning requesting a user action. Thank you! I have demonstrated that Etar application from F-Droid would disregard what is invalid and basically only enter valid time. Same for Google calendar, it would disregard invalid timestamp (even though not represented as above), and it would enter only valid one. PostgreSQL will "silently" ignore what does not belong to it. One can search for "silent" here: https://www.postgresql.org/docs/current/datatype-datetime.html > Could you explain what is wrong with the following (without timezone)? > > 2030-02-09 12:00 -0800 > > I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that is a > UTC timestamp. That is not same case as Ihor, when he designated it as 2030-02-09 12:00 -0800 @UTC because there are no offsets @UTC time zone. In this different case you wish to say that it is: time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time 2030-02-09 12:00, and one can derive UTC time. That is totally alright as representation of time. That is how past timestamps are represented in local time. Why not -- you can use it for future. I find it less useful for exchange purposes, almost useless, but you can do. Because if you store time as UTC, you can always see local time anywhere in the world. But if programmers wish to do that to Org, okay fine. It is different time type representation, that does not exist in ISO 8601, but why not, you can include it in Org. You just be sure that you put a "tag" or such representation that users will know what is it, even from plain text. > The format with explicit offset may be convenient for a person > living in an area that *likely* will have -08:00 offset and who > would like to watch some astronomical event such as lunar eclipse > and who had a plan to connect to some telescope on the opposite side > of the globe. Event time will not change if local time changed. Both > variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be > presented as "2030-02-09 12:00" to users. And now you speak of presentation. But then why store it with 2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z and have representation be same "2030-02-09 12:00" to users. So that is only addition to programmer. Remember that not even databases store the time like that. It is either UTC time, or date, time, and some time zone stored separately. > If timezone offset is changed both variants will converted to > "13:00" or "11:00" depending on sign of change. Correct. I understand you want to say that representation of time for that UTC time zone will be modified depnding of change, and that is correct. > So the format with offset is human friendly because it gives a hint > concerning *probable* value of local time still remaining *precise* > in respect to UTC. This representation of time is human friendly: 2030-02-09 12:00 -0800 and that is the way how I daily see my timestamps, like this: 2023-02-12 12:59:52.839773+03 which does not differ much from that one. However, my timestamp is only represented with +03 UTC offset. It is not stored with UTC offset. Storing values is not equal to representing values. - In other software values are not stored as "UTC time that has offset" - It is stored as "UTC time" - Offset is calculated from time zone and represented to user. Of course you need not follow what other software does. Though I think you need rather exact designation for users to unmistakably can understand what you mean with it: - Right now when I press C-c . I get: <2023-02-12 Sun> - C-u C-c . and I get <2023-02-12 Sun 13:03> - Then I can think you (developers) will invent something like: <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid invalid time stamps), which is UTC time: 2023-02-12 12:03:00 - Then I can think you would invent time stamp which you proposed, something like: <2023-02-12 12:00 -08:00> which in this case cannot have day representation, as one cannot know which day is that, right? And in this case that timestamp would mean it is 20:00 o'clock UTC time. And which can be replaced with <2023-02-12 20:00 @UTC> I am just not sure if that will be enough human friendly to say: <2023-02-12 12:00 -08:00> to people, as there is no designation that it is UTC time, and one cannot use "@UTC" as that would be wrong. Maybe designation is not necessary? When we consider how good calendars work, they will always ask user for the time zone. There is settings. And then if you write that event is on Sunday 20 o'clock, it will be considered 20 o'clock at that time zone. When you send it, it will be maybe converted to UTC time, but maybe not, maybe with time zone designation. In any case remote user will either get UTC time or date, time with time zone. Getting time representation with offset, to calculate UTC time seem redundant. But why not, it is possible. Will you do it, practically implement it? > I find the following as acceptable, but confusing to some degree: > > 2030-02-09 12:00 -08 > > just because "-08" is currently used in TZ database as time zone > abbreviation (a string similar to "BST"), not as offset that is represented > in wide spread formats as -0800 or -08:00. Unfortunately the latter causes > ambiguity in the context of Org. That is why is better not to use TZ time zone abbreviation for future times! For past times, is somehow okay. For future no. Let me consult the database. #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database rcdbusiness :dbuser maddox SELECT name, abbrev, utc_offset, is_dst FROM pg_timezone_names where abbrev = '-08'; #+END_SRC #+RESULTS: | name | abbrev | utc_offset | is_dst | |------------------------+--------+------------+--------| | Etc/GMT+8 | -08 | -08:00:00 | f | | Pacific/Pitcairn | -08 | -08:00:00 | f | | posix/Etc/GMT+8 | -08 | -08:00:00 | f | | posix/Pacific/Pitcairn | -08 | -08:00:00 | f | In your example, you should not use time zone abbreviations to say that it is UTC time with offset. Better use accurate offset (which is not UTC offset, as that is changeable). This is better if you really wish to designate the time with offset which represents UTC time: 2030-02-09 12:00 -08:00 Because you are rounding for no good reason! You have introduced new type of time storage, which is time with offset representing UTC time. While UTC offsets are mostly rounded, you are introducing not the UTC offset, but "offset". That means that following is also just fine: 2030-02-09 11:47 -08:12 Which is not common. But you insist on using time with offset, that represents UTC time, however, then you should not be using "UTC offsets" for such representations, but leave to users what "offset" to add or deduce, for UTC calculation. I am against such storage, and representation, but either: - as UTC time, without offset - or as date, time, time zone, as UTC offset can be calculated in future time points But we can see that Org is different case, it is textual, not database. However, this time: <2023-02-12 13:29> was always considered floating, and then by changing anything it can become [2023-02-13 Mon 13:29], the day is "added" automatically. So one needs some "tag" for time represented as UTC time but with offset, like [2023-02-13 13:29 @TO-UTC -08:00] it cannot be "@UTC" as that is time zone. You have to invent how to represent it, that is unmistakable to other representations. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
From: Jean Louis Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Date: Sun, 12 Feb 2023 13:32:21 +0300 User-agent: Mutt/2.2.9+54 (af2080d) (2022-11-21)