Re: Support for DATETIMEOFFSET

From: Jeremy Morton <admin(at)game-point(dot)net>
To: Neil <neil(at)fairwindsoft(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support for DATETIMEOFFSET
Date: 2020-04-10 23:10:54
Message-ID: 3f784fde-0a5d-8fdd-d90f-beb8d27a95c2@game-point.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil wrote:
>
>> On Apr 10, 2020, at 8:19 AM, Jeremy Morton <admin(at)game-point(dot)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….”

At just about every development shop I've worked for, I've seen
developers use methods to get a local DateTime - both in the DB and in
the code - such as DateTime.Now, and throw it at a DateTime field.
Heck, even I've occasionally forgotten to use .UtcNow. With
DateTimeOffset.Now, you can't go wrong. You get the UTC time, and the
offset. I've taken to using it 100% of the time. It's just really handy.

--
Best regards,
Jeremy Morton (Jez)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teja Mupparti 2020-04-10 23:59:58 Re: Corruption during WAL replay
Previous Message Tom Lane 2020-04-10 22:59:47 Re: Properly mark NULL returns in numeric aggregates