_creationTime format
Curious:
- why is
_creationTime a number instead of a string timestamp?
- why a decimal instead of a whole number of milliseconds?
I'm adding durable createdAt and updatedAt fields across my tables, just curious if there's a notable advantage for me.
I do like that string timestamps are human readable, but you kind of fix that in the dashboard anyway.2 Replies
it took us a lot of discussion to come to the current _creationTime format, and we're still considering changing it.
1. as numbers, they interact slightly better with
new Date(value) and comparison/math with Date.now(). string timestamps do work, and they are sortable if you do it right, but there might be confusion about time zones.
2. creation times have fractional milliseconds so they can be totally ordered within a transaction. if you write 5000 documents in a mutation, and the mutation takes 100ms, we can pick unique _creationTime for each document to give them ordering relative to each other (so db.query("messages").collect() is sorted by insertion time), while still staying within the 100ms range.
we have been considering changing the format to integer milliseconds, to better match Date.now(). any feedback you have is welcome.Gotcha. I haven't had any issues with the current format, I just hadn't seen the decimal approach. I don't think I realized they were fractional milliseconds either, I see the rationale behind representing that as a decimal.