> On Apr 10, 2020, at 8:19 AM, Jeremy Morton <admin@game-point.net> wrote:
>
> Oh well. Guess I keep using SQL Server then. datetimeoffset makes it impossible for developers to make the mistake
offorgetting to use UTC instead of local datetime, and for that reason alone it makes it invaluable in my opinion. It
shouldbe 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
datetime “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
zonein 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.
Isthis 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
extensionrather than for core PostgreSQL. For most applications the timestamptz and date types are enough to solve
everythingtime related (with some use of the timestamp type when doing calculations), but there are niche applications
whereother temporal types can be very useful, but I personally do not think those are common enough for inclusion in
corePostgreSQL.
>> I suggest writing an extension with this type and see if there is any interest in it.
>> Andreas
>
>