3 ms·
Surely you can do both, so you can still perform sane sorting/indexing on "real" timestamps and then use the extra precision string timestamp for drilling down?
by hnarn 6y ago
Surely you can do both, so you can still perform sane sorting/indexing on "real" timestamps and then use the extra precision string timestamp for drilling down?
- beagle3 6y agoIso8601 sorts just as well. I saw no benefit in storing two copies. That’s recipe for problems - e.g. “update” code that doesn’t update both, or somehow updates them differently (which one is right?). You can probably have t-sql or some “check” constraint to enforce equivalence, but ... why? For most practical uses, an ISO8601 textual representation is as good, though a little less space efficient.
- dragonwriter 6y ago> Iso8601 sorts just as well. No, it doesn’t, since all of the following are valid ISO 8601 representations of a date: 20210408 2021-04-07 2021-W14-1 2021W143 2021-097 2021098 (Now, consistently using any one of the ISO 8601 formats is sortable...)
- beagle3 6y agoPoint taken. I always recommend and use the specific ISO8601 format YYYY-MM-DDThh:mm:ss.sssZ (or drop the ".sss" if not needed), and be 100% consistent about it. But you are right, I shouldn't refer to this as "use ISO8601" because it is only one of the numeous possible formats described by that spec.