On 2020-Apr-17, Jeremy Morton wrote:
> How could the ORM use timestamptz when that doesn't actually store both a
> datetime and an offset?
There are lots of ways in which timestamptz can be used. The most
typical one is to rely on the TimeZone configuration parameter; another
very typical one is
How could the ORM use timestamptz when that doesn't actually store
both a datetime and an offset?
--
Best regards,
Jeremy Morton (Jez)
Tom Lane wrote:
Jeremy Morton writes:
Surely the fact that you'll lose data if you try to store a common
.NET datatype with any kind of ORM (eg. EF, which is
Jeremy Morton writes:
> Surely the fact that you'll lose data if you try to store a common
> .NET datatype with any kind of ORM (eg. EF, which is pretty popular)
> right now, using "the world's most advanced open source relational
> database", is reason enough to support it?
If the ORM somehow
On 4/17/20 11:00 AM, Jeremy Morton wrote:
I am not saying there isn't a use case for something like
datetimeoffset, I think that there is. For example in some kind of
Surely the fact that you'll lose data if you try to store a common .NET
datatype with any kind of ORM (eg. EF, which is pretty
Andreas Karlsson wrote:
On 4/10/20 3:19 PM, Jeremy Morton 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 opini
Jeremy Morton writes:
> 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
>
Neil wrote:
On Apr 10, 2020, at 8:19 AM, Jeremy Morton 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
opin
> On Apr 10, 2020, at 6:10 PM, Jeremy Morton wrote:
>
> Neil wrote:
>>> On Apr 10, 2020, at 8:19 AM, Jeremy Morton 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
On 4/10/20 3:19 PM, Jeremy Morton 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 un
lt, 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
>>> func
Jeremy Morton writes:
> 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,
Really? That would be a remarkable feat for a mere datatype to
accomplish.
> and for that reason
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
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'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.
--
Best regards,
Jeremy Morton (Jez)
14 matches
Mail list logo
