Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide methods for converting to java.time #254

Open
mjiderhamn opened this issue Mar 16, 2015 · 6 comments
Open

Provide methods for converting to java.time #254

mjiderhamn opened this issue Mar 16, 2015 · 6 comments
Labels

Comments

@mjiderhamn
Copy link

Just like Joda Time provides methods for converting to/from java.util.Date/Calendar, it would be beneficial - not least for migration - to provide methods to convert to/from the new Java 8 java.time classes, such as org.joda.time.LocalDate -> java.time.LocalDate.

@jodastephen
Copy link
Member

My preferred approach to this is to make the Joda-Time classes implement TemporalAccessor. Doing so requires forking the Joda-Time codebase (one for Java 5 and one for Java 8), which is quite a lot of effort to manage going forward.

@kevinb9n
Copy link

We are probably going to try that fork at least for our own internal purposes, since full java.time migration for us will take years.

@jodastephen
Copy link
Member

I would also suggest adding factory and instance methods to match Java 8. If you do fork publicly, I'm happy to advise.

@cpovirk
Copy link
Contributor

cpovirk commented May 9, 2018

We're planning to discuss this some tomorrow at Google. Is there anything else we should keep in mind? (Sorry for the late notice....)

One thing I'm wondering is whether it would be better to provide static conversion methods instead. They could go in a separate, Java-8-only artifact (presumably in a subpackage to avoid problems with modules). Naturally, this would be less convenient, and if Joda Time ever does require Java 8, it will be a wart that the methods live there instead of as instance methods. On the other hand, it avoids a Java 5 / Java 8 split, and we certainly understand the appeal of that :)

@kevinb9n
Copy link

kevinb9n commented May 9, 2018

(Subjectively, I feel that instance methods are quite a lot more readable, usable, findable, everything-able, and .... I want them!)

@jodastephen
Copy link
Member

I'm imagining that the goal would be to:

  • add interfaces like TemporalAccessor to classes like org.joda.time.LocalDate
  • add key factory methods like of(...) and from(...)
  • add key instance methods like at...()

Figuring out the exact list of these methods is the hard part of the task. Overall, my thought was to try and bring the API of Joda-Time close to that of JSR-310 simply by making the API larger.

I'm not too concerned about a Java 5 / Java 8 split, as Joda-Time is pretty stable and even if a bug is found it is often just be documented due to JDK-like backwards compatibility. Having a Java 8 only static helper doesn't seem like it would be that useful by comparison with full integration, so I'm with @kevinb9n there.

@jodastephen jodastephen added the v3 label Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants