Why are "date" fields forced to Date objects?

[markedwards]

It is reasonable and correct for "timestamp" fields to be converted to/from Javascript Date objects. But it is not reasonable that the same happens to "date" fields. This data type does not have a timezone or any time information at all, but it is being falsely added by pg.

Is there any chance at this point of this behavior changing? Other libraries like TypeORM are actually fixing this bad behavior, but not when raw query results are returned. Its super confusing.

[brianc]

I agree with you its a pretty bad design decision. Some of the decisions in this library are a bit crufty because I was 15 years my own junior when I started on it, and made the wrong choice. The situation currently is its installed millions of times a week and changing the type returned from a query is a relatively serious backwards compatibility issue in that its pretty hard to statically analyze your own code and check for incompatiblities since it'd be in your SQL text (and sometimes only in your db schema). So I totally agree with you, but I'm very slow on changing things. On top of that you get the whole free code thing and well...it can take time. But I hear you & this is on my radar of things to change. This very issue bit us on my own company several times. FWIW when we write plain text queries (which we do regularly as we don't use an ORM at all) we do something like `SELECT name, birthday::TEXT FROM users` or whatever. There is also a built in way in this library to relatively easily override the type parser for a given type. In this case you'd need to do a bit of digging (as I don't have the code in front of me...I'm on vacation ATM) but its only a couple lines long and then all your dates will be returned as text. As they should be. And you know that got me thinking...when I get back from vacation I'll do that in our own code because yeah definitely should.

…

On Mon, Aug 5, 2024 at 3:05 PM Mark Edwards ***@***.***> wrote: It is reasonable and correct for "timestamp" fields to be converted to/from Javascript Date objects. But it is not reasonable that the same happens to "date" fields. This data type does not have a timezone or any time information at all, but it is being falsely added by pg. Is there any chance at this point of this behavior changing? Other libraries like TypeORM are actually fixing this bad behavior, but not when raw query results are returned. Its super confusing. — Reply to this email directly, view it on GitHub <#3290>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMHIJJ63YX3GYR2YWCM53ZP7EIJAVCNFSM6AAAAABMA3RKISVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ2DSMRXG4ZTGOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[charmander]

Duplicate of #1844

[charmander]

Other libraries like TypeORM are actually fixing this bad behavior, but not when raw query results are returned.

Until pg gets the new major version of pg-types, libraries that depend on it should ideally be overriding the date type parser instead of converting the Date back into a string, which would also fix this kind of discrepancy.

[markedwards]

@brianc, just wanted to follow up belatedly here thank you for the fast and candid response. Many would have ignored this, or been defensive, and you gave a straight answer. Really appreciate that.

It would be great to see this fixed ultimately, but I fully understand the challenge here.

I'll bug TypeORM for a proper fix here, but unfortunately for now I have to settle for converting the value after the fact.