Hi, > But now (after big timeseries project with multiple time zones and DST > problems) I think differently. > Even though timestamp and timestamptz are practically the same, timestamptz > should be used to store the time in UTC. > Choosing timestamp is more likely to lead to problems and misunderstandings > than timestamptz.
As somebody who contributed TZ support to TimescaleDB I'm more or less aware about the pros and cons of Timestamp and TimestampTz :) Engineering is all about compromises. I can imagine a project where it makes sense to use only TimestampTz for the entire database, and the opposite - when it's better to use only UTC and Timestamp. In this particular case I was merely concerned that the particular choice could be confusing for the users but I think I changed my mind by now, see below. >> Here's v12. Changes: >> 1. Documentation improvements >> 2. Code comments >> 3. Better commit message and reviews list > > > Thank you, Andrey! I have just checked v12 – cleanly applied to HEAD, and > functions work well. I especially like that fact that we keep > uuid_extract_time(..) here – this is a great thing to have for time-based > partitioning, and in many cases we will be able to decide not to have a > creation column timestamp (e.g., "created_at") at all, saving 8 bytes. > > The docs and comments look great too. > > Overall, the patch looks mature enough. It would be great to have it in pg17. > Yes, the RFC is not fully finalized yet, but it's very close. And many > libraries are already including implementation of UUIDv7 – here are some > examples: > > - https://www.npmjs.com/package/uuidv7 > - https://crates.io/crates/uuidv7 > - https://github.com/google/uuid/pull/139 Thanks! After playing with v12 I'm inclined to agree that it's RfC. I only have a couple of silly nitpicks: - It could make sense to decompose the C implementation of uuidv7() in two functions, for readability. - It could make sense to get rid of curly braces in SQL tests when calling uuid_extract_ver() and uuid_extract_ver(), for consistency. I'm not going to insist on these changes though and prefer leaving it to the author and the committer to decide. Also I take back what I said above about using Timestamp instead of TimestampTz. I forgot that Timestamps are implicitly casted to TimestampTz's, so users preferring Timestamps can do this: ``` =# select uuidv7('2024-01-22 12:34:56' :: timestamp); uuidv7 -------------------------------------- 018d3085-de00-77c1-9e7b-7b04ddb9ebb9 ``` Cfbot also seems to be happy with the patch so I'm changing the CF entry status to RfC. -- Best regards, Aleksander Alekseev
