Re: UUID v7
От | Przemysław Sztoch |
---|---|
Тема | Re: UUID v7 |
Дата | |
Msg-id | f9e0f31e-86aa-37c6-b6b7-cb6b6155a850@sztoch.pl обсуждение исходный текст |
Ответ на | Re: UUID v7 (Andrey Borodin <x4mmm@yandex-team.ru>) |
Список | pgsql-hackers |
We are not allowed to consider any time other than UTC.
You need to write to the authors of the standard. I suppose this is a mistake.
I know from experience that errors in such standards most often appear in examples.
Nobody detects them at first.
Everyone reads and checks ideas, not calculations.
Then developers during implementation tears out their hair.
Andrey Borodin wrote on 1/18/2024 4:39 PM:
You need to write to the authors of the standard. I suppose this is a mistake.
I know from experience that errors in such standards most often appear in examples.
Nobody detects them at first.
Everyone reads and checks ideas, not calculations.
Then developers during implementation tears out their hair.
Andrey Borodin wrote on 1/18/2024 4:39 PM:
On 18 Jan 2024, at 19:20, Aleksander Alekseev <aleksander@timescale.com> wrote: Timestamp and TimestampTz are absolutely the same thing.My question is not about Postgres data types. I'm asking about examples in the standard. There's an example 017F22E2-79B0-7CC3-98C4-DC0C0C07398F. It is expected to be generated on "Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00". It's exaplained to be 164555774200000ns after 1582-10-15 00:00:00 UTC. But 164555774200000ns after 1582-10-15 00:00:00 UTC was 2022-02-22 19:22:22 UTC. And that was 2022-02-23 00:22:22 in UTC-05. Best regards, Andrey Borodin.
--
Przemysław Sztoch | Mobile +48 509 99 00 66
Przemysław Sztoch | Mobile +48 509 99 00 66
В списке pgsql-hackers по дате отправления: