pg-types @ 4.x is not backwards compatible, so it requires a major version bump (and a LOT of headache for library consumers)

I think there needs to be another fork or something of pg-types that does not do the date/time zone conversion differently. Unfortunately changing that would be insanely breaking for a lot of deployed code-bases even though the original decision 15 years ago wasn't the best....I'm not convinced its worth the forced upgrade there.

@brianc can you elaborate on what that means?

Also, does it make sense to use pg-types without node-postgres? If not, then why not move the source code for that library into this repo and tie their development together?

From what I can gather:

1. the Date objects will now be parsed to the current timezone even if they do not have timezone in them (which is why the test is failing). To fix this test, we could retrieve the timezone of the db connection and then add the offset.
2. postgres DATEs will be returned as string

But yeah, this should be a major version bump

But yeah, this should be a major version bump

I am leaning towards re-absorbing pg-types in some form into this monorepo & before incorporating it, reverting the breaking changes to the date parsing. Then it can be more tightly versioned w/ the rest of the code, benefit from the years of perf tweaks done to the stand alone pg-types library, and not cause massive, hard to catch breaking changes like what would happen if i just bumped pg-types in this library.

I am leaning towards re-absorbing pg-types in some form into this monorepo & before incorporating it, reverting the breaking changes to the date parsing. Then it can be more tightly versioned w/ the rest of the code, benefit from the years of perf tweaks done to the stand alone pg-types library, and not cause massive, hard to catch breaking changes like what would happen if i just bumped pg-types in this library.

That's the more reasonable move I think.
With a feature flag to enable the change on date parsing, so anyone could try it and start changing its code base for that.

@brianc is there a anything I can do to help?

@aqeelat thanks for asking - just getting over the flu...I think the biggest thing that would help, though it's quite a bit of effort, is fork pg-types@4.x and then change it so the existing tests under ./packages/pg pass without any moidifications to the pg codebase. There are tests around the date timezone and date returning an actual date ( I believe) that are failing that need to pass. Basically make a pg-types@5.x that is not a breaking change. Then it'll be really easy to absorb.