> On Apr 10, 2020, at 8:19 AM, Jeremy Morton <ad...@game-point.net> wrote: > > Oh well. Guess I keep using SQL Server then. datetimeoffset makes it > impossible for developers to make the mistake of forgetting to use UTC > instead of local datetime, and for that reason alone it makes it invaluable > in my opinion. It should be used universally instead of datetime.
1. Not sure I understand. I’ve never used datetimeoffset so please bear with me. How does storing a time zone with the date time “make it impossible for developers to make the mistake….” 2. I usually work with timestamps that have input and output across multiple time zones, why would one store a time zone in the database? If I need a local time, then postgres does that automatically. 3. At the end of the day a point in time in UTC is about as clear as it is possible to make it. Not trying to be difficult, just trying to understand. Neil > > -- > Best regards, > Jeremy Morton (Jez) > > Andreas Karlsson wrote: >> On 4/10/20 10:34 AM, Jeremy Morton wrote: >>> I've noticed that Postgres doesn't have support for DATETIMEOFFSET (or any >>> functional equivalent data type) yet. Is this on the roadmap to implement? >>> I find it a very useful data type that I use all over the place in TSQL >>> databases. >> Hi, >> I do not think anyone is working on such a type. And personally I think >> such a type is better suite for an extension rather than for core >> PostgreSQL. For most applications the timestamptz and date types are enough >> to solve everything time related (with some use of the timestamp type when >> doing calculations), but there are niche applications where other temporal >> types can be very useful, but I personally do not think those are common >> enough for inclusion in core PostgreSQL. >> I suggest writing an extension with this type and see if there is any >> interest in it. >> Andreas > >
