3 ms·
Improvement idea -- in my experience "valid_from" is always a date (no time, no timezone). That's how it's reported in documents (e.g. contract validity period)
by deepsun 1y ago
Improvement idea -- in my experience "valid_from" is always a date (no time, no timezone). That's how it's reported in documents (e.g. contract validity period).
Rows that need seconds (e.g. bank transactions) are events, they aren't "valid" from a particular point in time forward, they just happen.
- nine_k 1y agoIn my experience, validity time may start at the start of business day, and likely has a specific time zone. In particular, I've seen how documents related to stock trading at NASDAQ specify Eastern Standard Time as the applicable timezone. I understand how convenient it is to use UTC-only timestamps. It works in most cases but not all.
- adammarples 1y agoNo point losing information like that. What do you do if someone opens and closes an account on the same day? Changes their email address three times in one day? Etc
- deepsun 1y agoAgree, if your updates have time then datetime it should be. It's just in my work everything is date only. E.g. employment starts on a date, not datetime, there's no data loss.