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.
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...)
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.
Among the option of storing (date field, millisecond field) and (date as iso8601 text field with millisecond without time zone) I chose the latter, and I can’t tell for sure but it was almost surely the better choice.