Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQZKm-0028pG-SV for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2024 20:49:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rQZKj-005SX3-36 for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2024 20:49:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQZKi-005SWv-P1 for pgsql-hackers@lists.postgresql.org; Thu, 18 Jan 2024 20:49:52 +0000 Received: from mail.ltc.pl ([194.24.180.24]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQZKb-002WRv-Qb for pgsql-hackers@postgresql.org; Thu, 18 Jan 2024 20:49:52 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ltc.pl (Postfix) with ESMTP id D00ABDF9DD; Thu, 18 Jan 2024 21:49:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sztoch.pl; s=mail; t=1705610985; bh=c+jZfKlcDIM7MQfqAsE5hChjOWOPGQ9x19bw8TlV0q4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KW47oOfT4bOXmwTPfXXfH3fmwjVNxDgWXPylhG6XwEly6BQS/6h+cQW5QbMUFFkcJ efhBeFER+LfEB8X9k29Nmp8vWVkIJCw1WSKW3gWPFge7GyJXaCy0hdwWyJSPd6XGiM nOO05D/as4iXV5HsEfoeZzw1goY0riGpoo6gaoV6cwmG9ms5gdKSczv7eaeY2iuzQG vrch7FsNVNyTxcJyMdU68RO9uH391xOMyviwYDEIcK/pS6gX5vGupx9Dl3gbewV3Z5 tAqTv6Ar8GZeKlDeIRQb2o937cr5DNlPRjM2OC0rvk/qAUkk603SDQ7TjCZtxGNCIl 7kPtpOcl8qN5w== X-Virus-Scanned: Debian amavisd-new at mail.ltc.pl Received: from mail.ltc.pl ([127.0.0.1]) by localhost (mail.ltc.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z_AeOhbGuV23; Thu, 18 Jan 2024 21:49:28 +0100 (CET) Received: from [192.168.56.98] (fu182.internetdsl.tpnet.pl [80.53.46.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ltc.pl (Postfix) with ESMTPSA; Thu, 18 Jan 2024 21:49:28 +0100 (CET) Subject: Re: UUID v7 To: Andrey Borodin Cc: Aleksander Alekseev , pgsql-hackers mailing list , Sergey Prokhorenko , Jelte Fennema-Nio , Nick Babadzhanian , Mat Arye , Peter Eisentraut , Tom Lane , Daniel Gustafsson , Matthias van de Meent , Nikolay Samokhvalov , "Kyzer Davis (kydavis)" , Andres Freund , "brad@peabody.io" , Kirk Wolak References: <6941A45B-C7D4-414B-A3A9-ACED172DFBD5@yandex-team.ru> <8DB43887-CA09-4845-83C0-33E8A79D0711@yandex-team.ru> <1003561938.6914482.1704452267331@mail.yahoo.com> <80E8F728-FC9C-461E-9B61-332E3AAEC066@yandex-team.ru> <67eb8a02-f35c-af10-1615-afae0f9f7548@sztoch.pl> <8A52AED1-2CA6-403C-8B5B-D24EA8D58616@yandex-team.ru> From: =?UTF-8?Q?Przemys=c5=82aw_Sztoch?= Message-ID: Date: Thu, 18 Jan 2024 21:49:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.60 MIME-Version: 1.0 In-Reply-To: <8A52AED1-2CA6-403C-8B5B-D24EA8D58616@yandex-team.ru> Content-Type: multipart/alternative; boundary="------------E434B950764059EC0701FF72" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------E434B950764059EC0701FF72 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: > >> On 18 Jan 2024, at 19:20, Aleksander Alekseev 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 --------------E434B950764059EC0701FF72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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:


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