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>]

* Ihor Radchenko <yantar92@posteo.net> [2023-02-10 13:48]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > If you start adding in Org "fixed" time with UTC offset, that is a new
> > type of timestamp, as it is not common in world.
> 
> It is how ISO8601 defines offsets.

- did you say you wish to represent time with UTC time zone by using
  UTC offset?

- and I said, UTC time is always without offset, and if any is
  represented then it must be +00

- and now you say that ISO8601 defines offsets... sorry, you are
  confusing me and readers.

Please see here:
https://en.wikipedia.org/wiki/ISO_8601

on right side, there is representation of UTC time:
Date and time in UTC
2023-02-12T06:45:15+00:00
2023-02-12T06:45:15Z
20230212T064515Z

Do you see? There is no offset larger or smaller than zero.

We were discussing of a time stamp at @UTC time zone with offset!

That type of a timestamp does not exist.

What exists with positive or negative offset is timestamp with time
zone other but UTC.

But not with UTC.

If you do introduce positive or negative offsets at UTC time zone, you
are introducing something new in Org. It is not necessarily bad, but
IMHO you will create more confusion, for no good reason.

> > Here is suggestion:
> > -------------------
> >
> > 1. Convert local time timestamp to UTC
> > 2. Add 10024 hours
> > 3. Provide timestamp in UTC
> 
> This will involve converting time, which is prone to errors. I still
> think that sometimes it is more convenient for human to use familiar
> time zone and fix the offset for future.

Your answer is not related any more to @UTC time you were mentioning
as now you are using "familiar time zone". I said, there is no offset
representation with UTC time but +00. But it can be with other time
zones.

However, when you say "fix the offset for future" that does not
work. If you do specify time zone, you are fixing it by time zone, and
not by UTC offset, because it is less likely that the time zone
definition changes, but UTC offset can change easier.

The UTC offset is property of the time zone. The future time zone
definition will know what is it's UTC offset.

You can introduce something new in Org and say "This is fixed UTC
offset in time zone @ABC" but that way you are confusing yourself and
future programmer and users, as it does not comply to already accepted
international standards.

iCalendar proposes different way of representation of time in future,haw
that is, it could be UTC time in future, or it could be date, time and
time zone. Using UTC offset for future is redundant, as in present
time when you are writing future time stamp, you cannot know the
future UTC offset.

> > Also look at this reference:
> > https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
> >i
> > ,----
> > | The form of date and time with UTC offset MUST NOT be used. For
> > | example, the following is not valid for a DATE-TIME value:
> > | 
> > |  19980119T230000-0800       ;Invalid time format
> > `----
> 
> > As with the above format, author would maybe think it is alright, but
> > in general it is confusing. If author wish to specify UTC time, then
> > no offset shall be used.
> 
> icalendar is _not_ the only time spec around. We can take it into
> account, but I do not see any reason to follow it blindly.

How about finding reasons why iCalendar specifies it that way?

And then deciding if those reasons, not specification literally,
should be followed?

> Reading the linked RFC spec, I did note that the motivation for the time
> format used in calendar is mainly scheduling meetings for people
> residing in different time zones.

And I think that is what we are talking about, about conclusive time
representation in cases where Org users need it. If meeting or not,
that is something for users to decide.

Important is only to define the types of time stamps, and then let
users use it.

Goal is to improve Org timestamps so that Org get feature of
conclusive time representation.

That means to me, that inconclusive, like floating timestamps can be
left how they are, only new are added.

For past time representation is best using UTC timestamp, as such can
easily be converted to local time. But how? Using overlays? Or
updating time stamps in buffer? Or using updated local time timestamps
in exports?

There is that time stamp for future, if it should not be floating or
non-conclusive, then you use date, time and time zone.

You insist on "fixing UTC time offset for time zone", but I do not
understand that reasoning, as it is contradictory to time zone
database use per se.

> I can see how the icalendar format is reasonable within that
> specific purpose. I cannot see why Org timestamps should be limited
> to meetings.

"Meeting" is not for Org to specify, that is for user to specify what
it is.

It need not be meeting, any future representation is quite different
from past.

Past timestamps are more conclusive, than future.

Past time zone databases already exists, TZ database is rarely updated
with past time zones, they are already there. Only for historical
purposes past time zones may be updated. But very rarely.

You have got past, and future.

Any non-floating "present" timestamp is already past in the moment it
is created.

"Meeting" is not time type of a timestamp. It is action to take place. 

That action can be anything, leave that to users.

I am using various actions, like "call", "marketing campaign",
"directory action", "case", "action", "follow-up", "task", "plan",
"meeting", and various others. 

And not forget, "timestamp" is by computing definition always past.

In Org we are trying to inject future timestamps by thinking it is
"timestamp" while in other computing subjects timestamps is by rule
always past and not future.

References show that future shall be sheduled by using date, time and
time zone or by using UTC plainly.

Problem is how to represent or diferrentiate future from past in Org
type of a timestamp.

This would be alright for me:
<2023-03-10 Fri 10:24 @Europe/Berlin>

One would need to provide algorithm to Org as to avoid placing invalid
timestamps in future, and in future, Org would know how to ask TZ
database to derive the UTC offset.

> Note that the idea with (optionally) providing two time zones/offsets is
> also coming from a time spec in
> https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Please note:

- that document speaks of timestamps in it's definition, that means
  "timestamp is represntation of past time".

- It references: https://www.rfc-editor.org/rfc/rfc3339 if you read
  introduction, it says "when representing and using date and time in
  Internet protocols" (Org is not Internet protocol), and then "There
  are many ways in which date and time values might appear in Internet
  protocols: this document focuses on just one common usage,
  viz. timestamps for Internet protocol events" (Org is not Internet
  protocol event)

- then your referenced document says "This document defines an
  extension syntax for timestamps as specified in [RFC3339] that has
  the following properties"

- then your above referenced document further says "This document does
  not address extensions to the format where the semantic result is no
  longer a fixed timestamp that is referenced to a (past or future)
  UTC time.  For instance, it does not address:

   *  Future time given as a local time in some specified time zone,
      where changes to the definition of that time zone (e.g., a
      political decision to enact or rescind daylight saving time)
      affect the instant in time corresponding with the timestamp."

Conclusion is that your reference is only partially relevant, as you
may use it as guide for past timestamps, but not as guide for future
time representation.

> Considering that the idea with "!" has been independently proposed
> within the current discussion, I assess that allowing two time zones ca
> be useful.

After I told you above, maybe you should re-consider how did you draw
those conclusions. I do not see how your idea is analogous to what
documents speak about.

> Please remember that this format is optional. If it is not useful for
> your use cases, feel free to specify a single time zone.

For myself is less important, I can create timestamps in Org how I
wish and want. In general for future, I am using structured time
representation, same thing what is recommended internationally.

                      Time zone   nil
            Start Date and Time   "2023-02-10 06:31:57.919956+03"
              End Date and Time   nil

- begin timestamp is with time zone representation, +03, it is only
  represented that way, but that is UTC time.

- only if there is time zone defined, then the UTC offset will be
  disregarded, and new time calculated by using the time zone's
  definition and it's UTC offset.

That is same thing as iCalendar, or any other software that knows how
to deal with time, I just coupled it together and made conditional.

My Org use is very structured. I use Org or any markup with
properties. And I mix markups like Org, LaTeX, Asciidoc, all in one
document. In same way my timestamps are separated from Org objects.

Thus for this representation:

                      Time zone   nil
            Start Date and Time   "2023-02-10 06:31:57.919956+03"
              End Date and Time   nil

That is UTC time and it will be displayed in my local time zone as:

2023-02-10 06:31:57.919956+03

but if I would be in Europe/Berlin time zone, it would be displayed as:

2023-02-10 04:31:57.919956+01

How is Org going to display a timestamp in local time when it is
stored in UTC time?

It needs either re-writing of a buffer, or temporary preview, or
conversions during export.

And when my time representation has any time zone, then it is
displayed in that time zone:

                      Time zone   "Asia/Kuching"
            Start Date and Time   "2023-02-10 06:31:57.919956+03"
              End Date and Time   nil

In this case, it will be represented in my local time, but this way:

2023-02-10 11:31:57.919956+03

In my case where I keep timestamps as properties separate from Org
objects, it is very easy to get such representations:

SELECT 
  CASE WHEN hyobjects_timezones IS NULL 
  THEN hyobjects_date
       ELSE hyobjects_date AT TIME ZONE hyobjects_timezones 
       END 
  FROM hyobjects WHERE hyobjects_id = 79134;

As I rely on PostgreSQL database and their authors, and it spares me
programming efforts tremendously.

There are many use cases where past representation should NOT be
represented with UTC time. 

Let me remind you that those documents were referring mostly to
Internet time protocols, not to human representation of time.

When person is born, that person knows the date, but the date is tied
to location. 

Thus representing birth date and birth tim with UTC time is of no
use. Hospital will tell it was date of 2023-02-12 and 06:00
o'clock. The time zone is forgotten in such representations, only
local people could derive the time zone. Practically UTC time in such
representation is only confusing. It may be represented in UTC time,
but what really matters is not the UTC time but local time. So local
time must be seen with eyes, even if stored with UTC time.

For this specific birth date case, I always write time with time
zone. That means that UTC time is not to be seen or calculated, but
only the date, time and time zone information.

There are other cases where past time is practically better
represented with the time zone.

For future time, it is alright for me personally to specify it with
the UTC time if such future moments are not really too far in future,
as it is unlikely really that my work.

Though if there are multiple people involved, then I have to represent
it better, and have to say about the time zone.

I am choosing the time zone by using completion. If you need this way
of completing, let me know, I can provide the list of time zones for
purposes of completion in Org.

Here is video of how I select time zones:
https://gnu.support/images/2023/02/2023-02-12/2023-02-12-11:05:15.ogv

In my opinion people should be given the extended timestamp function
in Org where they may choose the time zone.

- no C-u prefix, interactive selection: <2023-02-12 Sun>

- with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09>

- with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Sun 11:10>

- but then I do not know what with 3 times C-u, some of those prefixes
  could be used to let user choose the time zone

> >> I would like to remind you that timestamps are not necessarily used for
> >> meetings. And not always shared with other people.
> >
> > Ok, and I have asked you to provide practical examples.
> 
> And I did, in one of the previous replies - scientific experiment.
> Another example can be solar eclipse.

Thank you, that is good.

I have provided examples myself too in this email.

As you say, solar eclipse is future time event that in my opinion
could be represented with the UTC time and displayed to users in their
local time.

> > Timestamps for past time, like for logs, I always store as UTC time in
> > database, with time zone (which does not mean that time zone is
> > stored, but displayed in local time zone).
> 
> For Org, the aim is not to rely solely on programmatically calculating
> time in current time zone. It should be possible to create timestamps
> readable in raw text. UTC may be readable for some people, but not for
> others. Of course, you can put UTC timestamps in your files, if you
> prefer. But more general timestamp format should permit different use
> cases.

I totally agree and that is reason why I am writing, I agree it is
good for human to have it readable.

> > 4. Hypothetical example of clear timestamp for future:
> >    [2024-02-04 12:00! @-08,America/Vancouver]
> >    where the time would be stamped with "!" and that would mean that in the time zone, meeting is at 12 o'clock.
> >    It would assume that UTC offset can change in future, but 12:00 clock would be authoritative time for future.
> 
> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?

The sign "!" is telling "use time, not offset as authoritative". I do
not say you should implement it this way, but I am saying it is wrong
putting both the time and offset for future time, while you will not
know the future offset with certainty.

It is not good specifying something in Org program and not clearly
giving it to user what is authoritative.

It is either the UTC time, or date, time plus time zone. 

It is not ambigious, it is example that remedies your ambigious
example.

You said: [2024-02-04 12:00 @-08,America/Vancouver] -- would be
counted with fixed UTC offset. So fixed from what? Fixed from time
zone America/Vancouver? Fixed form time represented 2023-02-04 12:00?

When those parts are separate fields, picture becomes clear:

                      Time zone   "America/Vancouver"
            Start Date and Time   "2023-02-04 12:00:00+03"
              End Date and Time   nil

From this time stamp, user seeing it in plain text, cannot know if Org
program means that time 12 o'clock is authoritative or that some
"fixed offset" is used:

[2024-02-04 12:00 @-08,America/Vancouver]

- you said, you wish to use "fixed offset" from UTC, but than if it is
  fixed, you better use UTC straight, and not wrong representation. It
  is wrong because it is not ordinary. It is either time zone which
  will tell what is offset in future, or it is UTC time which has no
  offset. 

- it is not visible in the time representation that you mean "fixed
  offset", because traditionally offsets are calculated from time zone
  database, and not from past representation!

- traditionally UTC offset is used with local time in order to
  calculate what is UTC. 12:00 -08, means 04:00 UTC time.

- you have introduced confusion, telling that you wish to represent
  time also with @UTC time zone but with offset, that is
  contradictory. 

- OK fine, if I assume that you wish to use "fixed UTC offset in
  future", that means you contradict to time zone definitions, you do
  not even need the time zones! [2024-02-04 12:00 @-08] would mean
  that UTC time is 20:00 o'clock, and that is UTC time. Why do you
  need time zone if you wish to say that it is fixed UTC offset? Time
  zone is used for reason that UTC offsets are not fixed and we have
  to derive it from their definitions.

In general I see you have got it messed up with introduction of:

1. Timestamps @UTC time zone with UTC offsets as they are
   contradictory to international standards and agreements of time
   representation.

2. Timestamps with "fixed UTC offset" where you specify time zone, it
   is contradictory. 

Sure you need not follow international recommendations for future
events, but that will not make Org more useful in that regard of time
representation.

The GMT-08 time zone you mentioned is not authoriative, I could say it
is supplementary.

Can you choose GMT-08 by using `tzselect' command? Wonder why...

[2024-02-04 12:00! @-08,America/Vancouver] is not ambigous, because it
says "America/Vancouver" and has "!" to indicate that 12 o'clock is
authoritative time. I made this only hypothetically for you to
understand that people will not understand the difference by looking
into text like this: [2024-02-04 12:00 @-08,America/Vancouver] where
you said that "this is fixed UTC offset", as one cannot derive from
text alone what you mean!

But this way it can be derived eventually:

[2024-02-04 12:00! @-08,America/Vancouver] -- it means 12 o'clock at
America/Vancouver time zone in future, UTC offset at time point of
planning was -08, but is disregarded as America/Vancouver time zone in
future must be consulted and UTC offset how it will defined in future
must be used as authoritative.

[2024-02-04 12:00 @-08!,America/Vancouver] -- it means it MUST be -08
offset from time 2024-02-04 12:00, but that would indicate UTC time,
so it is useless and confusing to mention "America/Vancouver" as:
[2024-02-04 12:00 @-08!] would be enough as that would be UTC time,
but nowhere is written it is UTC time, it becomes consuing because
ordinary time representation is not represented with UTC offset
without time zone. Then it would be better: [2024-02-04 04:00 @UTC]
as that becomes clear.

The time zone database defines everything. Dwell inside of it. Resarch
it. Do not create new types of time representation.

In case of political changes, the time zone database will again
re-define it, so that local time of that representation can be
displayed with accuracy.

> >> > Maybe this way (hypothetically):
> >> >
> >> > [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]
> >> >
> >> > as that way you would give signal to program that you want UTC fixed
> >> > time in future, and not 12:00 o'clock necessary.
> >> 
> >> I am sorry, but I don't understand what you mean by UTC-FIXED.
> >
> > You mentioned it, you wish to have offset and to remain UTC fixed.
> >
> > And UTC is not fixed, it is either UTC without offset, or time zone
> > with UTC offset.
> >
> > But if you do wish, you have to make "tag" somehow, for computer
> > program to know what you mean, "UTC-FIXED" is only hypothetical tag.
> 
> Sorry but I still don't understand.
> For me, -08 is GMT+08 nautical time zone. Short form.
> America/Vancouver is a time zone.
> What is America/Vancouver/UTC-FIXED?

It is my attempt to help you understand that time representation type
is not visibl from the timestamp, for the reason that you introduced 2
different time representation types, you introduced:

- timestamp @UTC time zone with UTC offset, this does not exist
  anywhere, only in your idea so far, and I hope it will never be
  implemented, and if it does get implemented I have to file bugs on
  it

- timestamp with time zone other but UTC where you are talking about
  "fixed UTC offset" which is known that it is not fixed, whereby time
  zones are used to derive that future UTC time offset. You can fix it
  for past, not for future.

- thus "UTC-FIXED" is only a different "tag" on the timestamp, to make
  it hypothetically clear in plain text what you really mean

- you forgot that user cannot see your intention from 
  [2024-02-04 12:00 @-08, America/Vancouver]
  in case where you say "UTC offset is fixed"

- what if I as user think that is 12 o'clock in America/Vancouver
  time? 

- and you think as programmer "This is UTC fixed offset", but where is
  designation in that text that it is so?

- I provided examples how to designate it:

  1. [2024-02-04 12:00 @-08!, America/Vancouver] -- means your
     imaginary UTC fixed one (I hope you will understand and drop it),
     this is same as 20 o'clock UTC time, why do you show
     America/Vancouver? Show UTC only.

  2. [2024-02-04 12:00! @-08, America/Vancouver] -- means 12 o'clock
     at America/Vancouver time, no matter the offset. Original offset
     was -08, but new offset in future could be something else and
     must be derived from America/Vancouver time zone.

  3. [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] is same as
     example number 1, just with different tag. 

  4. Do not do that in 1 or 3, that is not what software does. It is
     new type you are trying to implement because you think with best
     intentions, but to me is obvious that you have to research it
     more.

> >> It is sometimes easier to define UTC time +offset instead of doing an
> >> extra conversion in your head.
> >
> > I hope you understood the difference.
> >
> > Providing UTC time plus some offset is inconclusive. It is idea that
> > is not aligned with what international community is doing.
> >
> > Provide UTC time.
> >
> > Or provide time zone plus UTC offset.
> >
> > Your idea as such is alright, but is individual, and it has to be
> > coordinated with what other programs are doing. Otherwise it become
> > confusing.
> >
> > Remember the reference on iCalendar, "not do do that". 
> >
> > iCalendar provides either UTC time, or date, time and time zone.
> 
> iCalendar is not the only source of truth. The suggested offsets are
> what ISO8601 defines. 

Just that you did not use ISO 8601 principles. You mixed something up.

Where does ISO 8601 advises using date, time, with time zone being UTC
by using UTC offset other but zero? 

Show me one example. I have shown you on Wikipedia example of ISO 8601
timestamp by using UTC time. There is no offset.

Timestamp stored in computers is mostly stored in UTC time. 

Then UTC offset is shown only to user looking at it in local time or
different time zones.

Read here:
https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC)

,----
| If the time is in UTC, add a Z directly after the time without a
| space. Z is the zone designator for the zero UTC offset. "09:30 UTC"
| is therefore represented as "09:30Z" or "T0930Z". "14:45:15 UTC" would
| be "14:45:15Z" or "T144515Z".
`----

Thus when representing UTC time, do not use UTC offset. That will
confuse people and is what I am talking about "the new Org time type
representation".

Read here:
https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC

,----
| The UTC offset is appended to the time in the same way that 'Z' was
| above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh].
| 
| Negative UTC offsets describe a time zone west of UTC±00:00, where the
| civil time is behind (or earlier) than UTC so the zone designator will
| look like "−03:00","−0300", or "−03".
`----

It EITHER -- OR condition. It is either UTC time, OR time with UTC
offset, because UTC time could only be represented with zero
offset. For that reason I believe "Z" is used for UTC time.

Then read examples of UTC offsets:

,----
| The following times all refer to the same moment: "18:30Z",
| "22:30+04", "1130−0700", and "15:00−03:30". Nautical time zone letters
| are not used with the exception of Z. To calculate UTC time one has to
| subtract the offset from the local time, e.g. for "15:00−03:30" do
| 15:00 − (−03:30) to get 18:30 UTC. 
`----

You mentioned ISO 8601, and I also wish to put your attention on it,
so we agree both that the time representation should be aligned with
what is commonly used in ISO 8601. Right?

Only that I do not agree that you are interpreting it right, for
reason that you use date, time, UTC negativ/positive offset at UTC
time zone.

UTC offset at UTC time zone is zero. Nothing else, never.

> iCalendar explicitly disregards the fixed offsets for some
> iCalendar-specific reasons. It is iCalendar that is not being
> aligned with more common standard.

It is.

Your interpretation is not.

> >> > Then it becomes clear that it will be the UTC offset in future with
> >> > assumed mentiond time zone.
> >> >
> >> > But if you mix UTC offset, plus the time zone for future, that makes
> >> > little sense, unless you introduce some tags that timestamp is
> >> > recognizable as using UTC time, or that it uses date/time and time
> >> 
> >> The problem being addressed with @+08,!Asia/Singapore is possible future
> >> change in time zone.
> >
> > That problem is solved, if you use TZ database:
> >
> > - in case of change of time zone, the TZ database will provide future
> >   adjustment, there may be new name of new time zone. 
> >
> > - in case of change of UTC offset, the TZ database in future will know
> >   it. 
> 
> Your statement is true only when TZ database is guaranteed to be
> up-to-date. It is not always the case. Consider opening an Org document
> on machine with out-of-date TZ database.

Of course.

And you are not making it compatible to outdated TZ databases!

You are making it compatible to present and future TZ databases!

In general, you can also leave org with floating timestamps, as very
few people will get affected, if at all.

Most of professiona people cannot use Org for meeting and
appointments, and collaborative time management!

Org is single user application.

What we are talking here about is trivial when MySQL or MariaDB or
PostgreSQL is used. 

Majority of ERP software runs on such databases, they use functions
that matter.

Org is not for that, and will never be without some serious and
striking integration efforts.

It means, do not strive for absolute accuracy.

Strive for simplicity.

> > I will never miss the meeting provided program consults TZ database.
> 
> You will not. But I can see myself missing the meeting and assuming the
> time "as usual".

Of course everything in our life is conditional.

Maybe the planet will stop moving, it must stop and disintegrate at
one point of time in future.

We speak of reality that is in present time, TZ database is being
updated, and is our current reality.

Time Zone Database:
https://www.iana.org/time-zones

I also do not consider it "authoritative" as it is in hands of United
States.

In case of international war, they can corrupt it, and corrupt other
countries time.

It is not something "universally" accessible, it relies on consensus,
and is not under our people' control. It has to be updated with
political statuses.

Too many conditions! It is constantly updated work and effort.

> > But if I have 2 timestamps, that is different situation.
> >
> > You need no UTC offset for future time representation.
> >
> > Also good to read:
> > https://engineering.q42.nl/why-always-use-utc-is-bad-advice/
> >
> > Also good to read:
> > https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/
> 
> The second link illustrates exactly UTC offset + also time zone name.
> Similar to what I proposed.

Remember, you started by showing UTC offset with UTC time zone, and
only for that specific case I told you that is not how it works and
how time should be represented.

I think you are referring to following, do you?
-----------------------------------------------

From:
https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/

,----
| "You have an appointment today at 3pm" is tricky. Your server runs in
| UTC (usually), the user is who knows where. Their 3pm is not your
| server's 3pm 💩
| 
| One solution is to save time with a UTC offset.
| 
| Like this:
| 
| 2022-03-09T15:00:00-08:00
| 
| Instead of Z for zulu time, we have an offset that says this time is 8 hours behind UTC. At 3pm.
| 
| Now your server understands the user's intention of 3pm and the exact
| point in time for UTC. Fantastic.
`----

That is his idea! But that idea is incorrect, I am sorry as I did not
refer to that idea, but other parts on article.

That guy never implemented that idea for reason that it simply does
not work!

There is no such type of time types in the PostgreSQL or MySQL
database.

You can only get the representation by program.

Example:

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
CREATE TABLE example (time TIMESTAMP WITH TIME ZONE);
#+END_SRC

#+RESULTS:
| CREATE TABLE |
|--------------|

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
INSERT INTO example (time) VALUES ('2023-02-12 12:00-03:00');
#+END_SRC

#+RESULTS:
| INSERT 0 1 |
|------------|

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
SELECT * FROM example ORDER BY time DESC;
#+END_SRC

#+RESULTS:
| time                   |
|------------------------|
| 2023-02-12 18:00:00+03 |
| 2023-02-12 18:00:00+03 |

Or we try without time zone?

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
CREATE TABLE example_without (time TIMESTAMP WITHOUT TIME ZONE);
#+END_SRC

#+RESULTS:
| CREATE TABLE |
|--------------|


#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
INSERT INTO example_without (time) VALUES ('2023-02-12 12:00-03:00');
#+END_SRC

#+RESULTS:
| INSERT 0 1 |
|------------|

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
SELECT * FROM example_without ORDER BY time DESC;
#+END_SRC

#+RESULTS:
| time                |
|---------------------|
| 2023-02-12 12:00:00 |

As you can see, you and that guy, you got similar idea, but that does
not exist in software.

What can be done is to record time with offset as text.

Or it can be recorded as date, time without time zone, without offset, but with offset being separate.

However, I repeat, that is totally out of what other software and other programmers do.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/