Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis <bugs@gnu.support>]

* 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/