|
|
|
|
|
|
by d_watt
1591 days ago
|
|
|
It depends on the implementation and definition of “datetime” in whatever you’re working with. Taking Postgres as an example: date: the concept of a calendar date (Your birthday) timestamp: the concept of of a calendar datetime (You should get a new years kiss at 2022-01-01 00:00) timestamptz: the concept of a precise moment in history (This comment was written at xxx time utc) You can design a system where timestamps/datetimes are considered to be precise moments in time, utc, but that’s a matter of the impmentation you’re dealing with. Again, postgres does not assume timestamps as being in UTC (which has messed me up on more than one occasion). |
|
|
I just had a long-standing bug come to the fore because I shifted a view to a materialized view, and embedded deep down in it was a date cast from a time stamp with tome zone.
When running as a view, everything was done in the user's time zone (because tits set per connection). When it’s a materialized view, it's he refresher's time zone.
This led to some inconsistencies, as the server is properly but inconveniently in UTC.