Getting following in CI build.. :/

docker: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit.

Hi, thanks for the PR!
There was some interest for it in the past. For reference see #131 and #157.
Ideally, if we could have both implementation as a non-breaking change it would be preferred.
But I understand this might complicate things a lot.
Since this is a breaking change we will need to bump the major version when merged.

I could try to have Joda Time supported as well. But the thing is, do we really want to continue supporting it?
I prefer the major version upgrade. But seems odd going from 1.1.7 to 2.0.0.
Suggestions on how to move forward with this please?

Bump version to 2.0.0 sounds reasonable to me.
Please rebase changes from master again, build should work now in CI.

Note that some tests are still failing on CI.

I fixed most. Just having issues understanding logic behind

I fixed most. Just having issues understanding logic behind

jasync-sql/postgresql-async/src/test/java/com/github/aysnc/sql/db/integration/TimeAndDateSpec.kt

Line 151 in 152cdef

assertThat(dateTime.millis).isGreaterThan(915779106000L)

can you help, @oshai ?

I didn't wrote it originally, but from reading the code I think it checks the following:

• set timestamp that includes mills/micros
• check that the timestamp millis conversion is greater than the second before and smaller from the second after

There might be a problem either with the timezone or the millis if I have to guess.

I noticed something, postgres is returning timestamps in UTC string, even when I insert it with non UTC offset.
The tests are expecting non UTC offset. So I changed a bit and is actually testing if the two timestamps are equal as OffsetDateTime
Is this correct approach?
I am guessing postgres returning UTC string is related to server settings (which I am not really changing). Is this correct assumption?

Codecov Report

Merging #233 (c8313ef) into master (a5a881f) will increase coverage by 0.14%.
The diff coverage is 64.28%.

@@             Coverage Diff              @@
##             master     #233      +/-   ##
============================================
+ Coverage     80.03%   80.17%   +0.14%     
- Complexity     1074     1079       +5     
============================================
  Files           265      266       +1     
  Lines          3916     3919       +3     
  Branches        522      523       +1     
============================================
+ Hits           3134     3142       +8     
+ Misses          534      531       -3     
+ Partials        248      246       -2     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a5a881f...c8313ef. Read the comment docs.

I noticed something, postgres is returning timestamps in UTC string, even when I insert it with non UTC offset.
The tests are expecting non UTC offset. So I changed a bit and is actually testing if the two timestamps are equal as OffsetDateTime
Is this correct approach?
I am guessing postgres returning UTC string is related to server settings (which I am not really changing). Is this correct assumption?

According to https://www.postgresql.org/docs/9.1/datatype-datetime.html 8.5.2. Date/Time Output:

The default is the ISO format
and it looks like:

ISO | ISO 8601/SQL standard | 1997-12-17 07:37:16-08

(without time zone)

Conversion on test makes sense (to see it's the same date as inserted). It's just not clear how this was changed from pervious impl.

I still need to review all changes, but it will take some time.

I saw that in some cases there is no test coverage: do you think it's an issue with the framework, or can you please add tests to cover those cases?

Can you point me to which cases are you talking about specifically?

I saw in many places move from millis to nano. Is it because java 8 uses nano and joda/db use millis?

Yes. Java uses nano, joda uses millis, db micro(at least in mysql)

Can you point me to which cases are you talking about specifically?

Look at LocalDateTimeEncoderDecoder:17 and see more examples in 'files changed' with the warning: Added line #Lxx was not covered by tests

@dragneelfps before merging there was still one answered question in the review about DATETIME(6).

In addition, will you have some time to improve test coverage?

Stale pull request message

I will merge this PR soon. Will create 1.x branch before that.

Thanks for the PR!
I merged it and will release a new version and update docs soon.