4 ms·
Iso8601 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 update
by beagle3 6y ago
Iso8601 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.