Re: UUID v7

Aleksander Alekseev wrote on 1/18/2024 3:20 PM:
> Hi,
>
>> Another question: how did you choose between using TimestampTz and
>> Timestamp types? I realize that internally it's all the same. Maybe
>> Timestamp will be slightly better since the way it is displayed
>> doesn't depend on the session settings. Many people I talked to find
>> this part of TimestampTz confusing.
>>
>> timstamptz internally always store UTC.
>> I believe that in SQL, when operating with time in UTC, you should always use timestamptz.
>> timestamp is theoretically the same thing. But internally it does not convert time to UTC and will lead to incorrect use.
> No.
>
> Timestamp and TimestampTz are absolutely the same thing. The only
> difference is how they are shown to the user. TimestampTz uses session
> context in order to be displayed in the TZ chosen by the user. Thus
> typically it is somewhat more confusing to the users and thus I asked
> whether there was a good reason to choose TimestampTz over Timestamp.
>

Theoretically, you're right. But look at this example:

SET timezone TO 'Europe/Warsaw';
SELECT extract(epoch from '2024-01-18 9:27:30'::timestamp),
extract(epoch from '2024-01-18 9:27:30'::timestamptz);

 date_part  | date_part
------------+------------
 1705570050 | 1705566450
(1 row)

In my opinion, timestamptz gives greater guarantees that the time
internally is in UTC and the user gets the time in his/her time zone.

In the case of timestamp, it is never certain whether it keeps time in
UTC or in the local zone.

In the case of argument's type, there would be no problem because we
could create two functions.
Of course timestamp would be treated the same as timestamptz.
But here we have a problem with the function return type, which can only
be one. And since the time returned is in UTC, it should be timestamptz.

--
Przemysław Sztoch | Mobile +48 509 99 00 66