<headius[m]>
this is intended to deprecate all public APIs that receive or return joda DateTime in favor of java.time versions
<headius[m]>
the main risk I see is that it still uses DateTime internally so if these APIs are used heavily they will churn back and forth
<headius[m]>
the full conversion seems out of scope for me in 9.3 because the APIs are so different
<headius[m]>
but it could happen in 9.3.x if we see a churn problem, with a fair chunk of risk
<enebo[m]>
I wonder if we can see how this is typically used in like JSON or AR to get a handle on whether we will see any churn
<headius[m]>
any existing libraries will go through the DateTime versions right now, so they will go straight in
<headius[m]>
the new preferred APIs will churn at least one ZonedDateTime because we still use DateTime internally
<headius[m]>
I guess my problem here is that we want to deprecate these APIs but don't have time to fully convert
<headius[m]>
but fully converting would cause all existing external uses of DateTime APIs to waste objects
<headius[m]>
🤷♂️
<headius[m]>
or it might not matter either way
<enebo[m]>
So we definitely want to remove joda so we need to start the deprecation at some point
<headius[m]>
right
<headius[m]>
and there will be conversion lag in external libraries
<enebo[m]>
Having a reasonable replacement seems to be the question mark right. It may be ok but it might create more than it was
<headius[m]>
no matter what we do
<headius[m]>
right
<enebo[m]>
yeah
<headius[m]>
partial conversion means there is a migration API but it will be slower initially (by how much we do not know)
<headius[m]>
full conversion means there is a migration API and old API is slower forever
<enebo[m]>
full conversion needs to become a carrot at some point
<enebo[m]>
having new API potentially slower may not get many people to want to convert
<enebo[m]>
With that said I believe we both control the main external date consumers
<headius[m]>
we do
<headius[m]>
psych, json, AR
<headius[m]>
most of them do not use joda APIs though I would bet
<headius[m]>
they use millis or day/month/year/hour/min/sec sorts of APIs
<headius[m]>
actually Psych goes through Ruby to construct times and dates so that is fully under our control
<headius[m]>
I see no references to DateTime in either psych or json
<headius[m]>
and no references to RubyTime or RubyDate in json either
<headius[m]>
so both of those appear to just feed tokens back to Ruby mostly and Ruby constructs dates and times
<enebo[m]>
AR has imports to joda stuff
<headius[m]>
mmm ok
<enebo[m]>
most of this appears to be setting up a DateTime or DateTimeZone to create a RubyTime.newTime
<enebo[m]>
so no doubt we can just switch this since it is essentially only for creation. So however we get these instances in the first place just needs to stop creating those instances
<enebo[m]>
I cannot believe JDBC would return Joda so we must be doing this with the JDBC date results
<enebo[m]>
This may end up meaning JDBC will return what we are moving to so this will be less work once changed
<headius[m]>
yeah I am sure we are making the DateTime ourselves
<headius[m]>
I guess the big thing I have to accept is that either old or new API will be slow at any given time so it is a matter of mitigating the conversion
<headius[m]>
there's no way around that, and there's no way around some wasteful churn during the conversion period
<enebo[m]>
we could conceivably just version check in AR too
<enebo[m]>
@SuppressWarnings("deprecation")
<enebo[m]>
HAHAH
<enebo[m]>
DateTimeUtils in AR already has a lot of these markers on these so I suspect it is already using some deprecated APIs
<headius[m]>
yeah not surprising
<enebo[m]>
I guess I will have to load this thing and see how many of these methods are actually being used now
<enebo[m]>
ARJDBC never fully deleted some older code so some of this may be dead
<headius[m]>
I am going through other APIs that use DateTimeZone and doing a similar deprecate and replace
<headius[m]>
at this point I think we should just go with the API conversion and then try to complete the conversion internally in update releases or 9.4
<enebo[m]>
sure seems good. It will be fantastic to dump joda as a dep
<headius[m]>
yeah
<headius[m]>
some day
<headius[m]>
ugh this is so frustrating
<headius[m]>
I have mostly dealt with the DateTImeZone APIs but we have some public APIs that use Chronology and there are no docs on how to convert
<enebo[m]>
I saw your tweet
<enebo[m]>
I looked briefly at some use of the DateTime/DateTimeZone in ARJDBC
<enebo[m]>
It looks like we getRubyTime and then grab jd out of it and then manip/access which may involve using nothing or UTC as a timezone
<enebo[m]>
So if RubyTime uses something other than jd internally we can probably just switch to that. I do not see anythign where the zone is either null or UTC
<headius[m]>
yeah that part should not be too hard
<headius[m]>
I have imported a tiny defunct MIT-licensed conversion utility for DateTime and DateTImeZone
<headius[m]>
those two classes should be covered pretty well
<headius[m]>
if I just deprecate the Chronology stuff for now maybe nobody will care... they are public but who would be using them
<enebo[m]>
there is a mention of chronology somewhere in that util class but not the path I examined
<headius[m]>
someone using JRuby's Java API to work with Japanese dates or Muslim dates? Seems pretty unlikely
<headius[m]>
I am only doing public APIs FWIW... nothing package or private
<headius[m]>
the full conversion is a big job
<enebo[m]>
lopex: hello
<lopex[m]>
enebo: hi there
<headius[m]>
lopex: convert all these time API calls for me
<headius[m]>
last commit deprecated all remaining APIs using joda stuff, added replacements for any DateTime or DateTimeZone stuff, and cleaned up compile time deprecation warnings by either fixing or suppressing
<headius[m]>
bleh ok there are some red things I will fix... delayed results
<enebo[m]>
ok well I think it is fine from a quick look. At some point we will just drop the joda stuff and replace internally as Java API equivalent. The other option is to reverse this relationship and try and make josaToJava and store Java
<enebo[m]>
I can understand that is probably a larger gap to jump right now
<headius[m]>
oops
<headius[m]>
Error: test_system_with_conflicting_dir(TestSystem): Java::JavaIo::IOException: Cannot run program "java -version" (in directory "D:\a\jruby\jruby"): CreateProcess error=2, The system cannot find the file specified
<headius[m]>
no idea what that is...fail on Windows CI in that PR
<enebo[m]>
I am thinking about it from the perspective of JDBC though. In the end we will pay no cost making RubyTime other than the boxing
<enebo[m]>
but not without it?
<headius[m]>
ah, dependency convergence broke on master when I merged jnr updates, I will fix that on master
<enebo[m]>
Looks unrelated
<enebo[m]>
oh
<headius[m]>
enebo: what do you mean about JDBC
<enebo[m]>
we get jdbc time/date results and I was hoping they had a more direct mapping to Java Time apis
<headius[m]>
ah yeah they should
<headius[m]>
there will be a cost using java.time right now since we still convert to/from joda internally but that is the path forward
<headius[m]>
once we have the internals converted, though, that cost will go away again
<enebo[m]>
yeah and it will be potentially cheaper than before this deprecation addition
<enebo[m]>
headius: do you know if newer Java API has mechanism for gettimeofday?
<headius[m]>
ZonedDateTime.now()?
<headius[m]>
that is default ISO chronology in default zone for current locale
<enebo[m]>
why did intellij make git annotate so much less accessible
<enebo[m]>
I just see nagging stuff like '// FIXME: we should have a pure Java fallback in jnr-posix and Windows is missing gettimeofday impl'
<headius[m]>
hmm might already have been fixed
<headius[m]>
I did not try to clean up or fix things unrelated to deprecating joda
<enebo[m]>
oh yeah this is just an aside since we mentioned using a new API
<enebo[m]>
"new"
<headius[m]>
ok yeah
<headius[m]>
once we are using java.time everywhere there are other things that can be moved to it like jnr-posix time stuff possibly
<headius[m]>
most of the actual failures are due to stricter time zone names, I am adding appropriate fixes
ur5us__ has joined #jruby
ur5us__ has quit [Remote host closed the connection]
ur5us__ has joined #jruby
TimGitter[m] has quit [Ping timeout: 258 seconds]
ahorek[m] has quit [Ping timeout: 258 seconds]
chrisseaton[m] has quit [Ping timeout: 258 seconds]
liamwhiteGitter[ has quit [Ping timeout: 245 seconds]
RomainManni-Buca has quit [Ping timeout: 245 seconds]
enebo[m] has quit [Ping timeout: 258 seconds]
HarrisKauffman[m has quit [Ping timeout: 245 seconds]