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

Implement all java.time classes. #7

Open
nicolasstucki opened this issue Feb 2, 2016 · 39 comments
Open

Implement all java.time classes. #7

nicolasstucki opened this issue Feb 2, 2016 · 39 comments
Labels

Comments

@nicolasstucki
Copy link
Contributor

@nicolasstucki nicolasstucki commented Feb 2, 2016

  • java.time.Clock
  • java.time.Duration
  • java.time.Instant
  • java.time.LocalDate
  • java.time.LocalDateTime
  • java.time.LocalTime
  • java.time.MonthDay
  • java.time.OffsetDateTime
  • java.time.OffsetTime
  • java.time.Period
  • java.time.Year
  • java.time.YearMonth
  • java.time.ZonedDateTime
  • java.time.ZoneId
  • java.time.ZoneOffset
  • java.time.DayOfWeek
  • java.time.Month
  • java.time.DateTimeException
  • java.time.chrono.ChronoLocalDate
  • java.time.chrono.ChronoLocalDateTime<D extends ChronoLocalDate>
  • java.time.chrono.Chronology
  • java.time.chrono.ChronoPeriod
  • java.time.chrono.ChronoZonedDateTime<D extends ChronoLocalDate>
  • java.time.chrono.Era
  • java.time.chrono.AbstractChronology
  • java.time.chrono.HijrahChronology
  • java.time.chrono.HijrahDate
  • java.time.chrono.IsoChronology
  • java.time.chrono.JapaneseChronology
  • java.time.chrono.JapaneseDate
  • java.time.chrono.JapaneseEra
  • java.time.chrono.MinguoChronology
  • java.time.chrono.MinguoDate
  • java.time.chrono.ThaiBuddhistChronology
  • java.time.chrono.ThaiBuddhistDate
  • java.time.chrono.HijrahEra
  • java.time.chrono.IsoEra
  • java.time.chrono.MinguoEra
  • java.time.chrono.ThaiBuddhistEra
  • java.time.format.DateTimeFormatter
  • java.time.format.DateTimeFormatterBuilder
  • java.time.format.DecimalStyle
  • java.time.format.FormatStyle
  • java.time.format.ResolverStyle
  • java.time.format.SignStyle
  • java.time.format.TextStyle
  • java.time.format.DateTimeParseException
  • java.time.temporal.Temporal
  • java.time.temporal.TemporalAccessor
  • java.time.temporal.TemporalAdjuster
  • java.time.temporal.TemporalAmount
  • java.time.temporal.TemporalField
  • java.time.temporal.TemporalQuery<R>
  • java.time.temporal.TemporalUnit
  • java.time.temporal.IsoFields
  • java.time.temporal.JulianFields
  • java.time.temporal.TemporalAdjusters
  • java.time.temporal.TemporalQueries
  • java.time.temporal.ValueRange
  • java.time.temporal.WeekFields
  • java.time.temporal.ChronoField
  • java.time.temporal.ChronoUnit
  • java.time.temporal.UnsupportedTemporalTypeException
  • java.time.zone.ZoneOffsetTransition
  • java.time.zone.ZoneOffsetTransitionRule
  • java.time.zone.ZoneRules
  • java.time.zone.ZoneRulesProvider
  • java.time.zone.ZoneOffsetTransitionRule.TimeDefinition
  • java.time.zone.ZoneRulesException
@fedesilva
Copy link

@fedesilva fedesilva commented Apr 11, 2016

Is using ThreeTen backport possible, license wise? If yes, I'll start porting zoned date time (which I need).

https://github.com/ThreeTen/threetenbp
https://github.com/ThreeTen/threetenbp/blob/master/LICENSE.txt

@sjrd
Copy link
Member

@sjrd sjrd commented Apr 11, 2016

Yes, both ThreeTen and this repo are BSD 3-clause.

@rpiaggio
Copy link

@rpiaggio rpiaggio commented May 29, 2016

Does this mean that we can just copy/adapt from https://github.com/soc/threetenbp ?

@sjrd
Copy link
Member

@sjrd sjrd commented May 29, 2016

IANAL but yes.

@rpiaggio
Copy link

@rpiaggio rpiaggio commented Jun 14, 2016

I'll go one step further: can we just rename the package from https://github.com/soc/threetenbp from org.threeten.bp to java.time and have the whole funcionality?

(Sorry @nicolasstucki and @alonsodomin, I know this would sidestep the considerable effort you have already invested on the implemented classes).

Actually, I see that this is a goal of such library, the issue is that they cannot test yet on Scala.js: https://github.com/soc/threetenbp/issues/22

@alonsodomin
Copy link
Contributor

@alonsodomin alonsodomin commented Jun 16, 2016

@rpiaggio As you have seen, soc's idea in his fork is basically being able to rename the package namespace from org.threeten.bp to java.time and use it as drop in replacement. In theory, his idea of starting with a translated fork sounds more sensible that attempt a full rewrite from scratch (specially if in the end it's going to be released with it's own license and release cycle) but the tests are a massive wall to overcome, since in the translated fork they are all based on TestNG, which AFAIK is not supported in Scala.js. So either TestNG support is added to Scala.js or all the tests from the threeten fork are translated to JUnit, neither of both being a trivial task.

I initially started trying to use soc's version, the reason I then later move to contribute here was that, for my use case (a POC/pet project), I didn't need the full library in itself and I needed to do some Scala/Scala.js cross-compilation (hence the namespace was important). Either way, the "java time library" is massive so whatever is the final translation winning in Scala-land that will mean dropping a big amount of effort done in any of the current attempts. That wouldn't be an issue for me as long as this means eventually arriving to a version that works and can be trusted.

@mkotsbak
Copy link

@mkotsbak mkotsbak commented Jun 19, 2016

Well, importing the code from soc's repository and renaming the is not solving all issues with e.g. timezones, formatting and locale: https://github.com/soc/threetenbp/issues

It is already possible today to just build that project manually and use it. Focus should be on implementing the missing classes referenced.

@soc
Copy link

@soc soc commented Jul 7, 2016

@mkotsbak Carlos is doing a lot of great work in implementing locale support for Scala.js: soc/scala-java-time#24

@alonsodomin Carlos seems to have found a way to run tests using JUnit without having to rewrite every test from scratch. It remains to be seen whether this will work for fancy TestNG stuff like these data tables used in some tests as input.

We are also currently waiting for Scala-native cross-build support to compile to native, too.

@mkotsbak
Copy link

@mkotsbak mkotsbak commented Jul 7, 2016

Yes, I see that the progress seems to be very good at the moment!

@soc
Copy link

@soc soc commented Jul 7, 2016

I have also flipped the switch and renamed the repo from threetenbp to scala-java-time, bumped the version to 2.0-M1.

The idea is to have milestones while work is going on implementing the missing bits for Scala.js.
The last milestone release will feature the rename of the packages¹ and after that I'll release an RC and finalize 2.0.

¹ I'm still concerned about what this will mean regarding testing it on the JVM (might be necessary to use a JDK7?).

@alonsodomin
Copy link
Contributor

@alonsodomin alonsodomin commented Jul 7, 2016

@soc that actually sounds quite good. I should defo get a grip with it again as I'm hitting the limit of what I can do with this lib.

@soc
Copy link

@soc soc commented Jul 18, 2016

Just as a short update:

@cquiroz Is working on java.util.Locale and related java.text classes for formatting. First versions of scala-java-locales have already been published.

I continue working on scala-java-time and have published the first milestone, 2.0.0-M1 a while ago.
After that I continued with cleanups and replaced usage of java.util.ServiceLoader with platform-specific implementations/stubs.

Currently I'm implementing a ScalaJS plugin for TestNG so that we can run all the existing test suites in the browser.

@njouanin
Copy link

@njouanin njouanin commented Nov 5, 2016

Hi, I need the Instant.parse() method but it is not currently implemented. I don't know how much work it needs to get it implemented (needs DateTimeFormatter) but I can have a look. Is this job would be helpful for the project, and is the "copy/adapt" from threetenbp still a good way of starting ?

@njouanin
Copy link

@njouanin njouanin commented Nov 6, 2016

Yes, but it need DateTimeFormatter and DateTimeFormatBuilder which are not implemented currently. Problm is that these classes need a lot of denpendecy (TimeZone, ...) so this may be a long work. May be the easiest is to implement a 'hard' parsing directly in the parse method.

@njouanin
Copy link

@njouanin njouanin commented Nov 6, 2016

I've seen these classes. But, DateTimeFormatterBuilder imports ZoneId (not implemented in this repo) which imports ZoneRulesProvider (not implemented in this repo) and java.util.TimeZone (not implemented in scala-js ?), and so on...
So I mean that providing a complete implementation "from scratch" is a hard work (what you probably already know) so I guessed implementing parse() the hard way (extracting fields and computing the equivalent instant in seconds) doesn't need all these dependencies.

@soc
Copy link

@soc soc commented Nov 6, 2016

@njouanin Instant.parse does not accept a time offset:

scala> java.time.Instant.parse("2007-12-03T10:15:30+05")
java.time.format.DateTimeParseException: Text '2007-12-03T10:15:30+05' could not be parsed at index 19
  at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
  at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
  at java.time.Instant.parse(Instant.java:395)
  ... 27 elided

scala> java.time.Instant.parse("2007-12-03T10:15:30")
java.time.format.DateTimeParseException: Text '2007-12-03T10:15:30' could not be parsed at index 19
  at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
  at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
  at java.time.Instant.parse(Instant.java:395)
  ... 27 elided

scala> java.time.Instant.parse("2007-12-03T10:15:30Z")
res2: java.time.Instant = 2007-12-03T10:15:30Z

So there is no need to have any zone/offset implementation for this piece of functionality.

The threeten implementation works for the valid inputs I tested on both JVM and JS. Do you have any inputs which should work, but don't?

@njouanin
Copy link

@njouanin njouanin commented Nov 6, 2016

I've tried your threeten implementation, but I think it doesn't fit my needs. I'm writing a application with a Scala(Play) backend and a ScalaJS frontend. Both communicate through Ajax calls and I use circe on the frontend to parse json replies from the backend. Json objects are mapped to case classes which code is shared between the frontend and server code. Some of them contain java.time.Instant attributes, so I need to have a java.time.Instant class on the frontend. threeten provides a org.threeten.bp.Instant as I've seen.
So, contributing to this project seems interesting to me as it would provide a "transparent" java.time implementation. In the mean time I see some other efforts (your) to implement this API in a "different" way, so I wonder which one to choose.

@soc
Copy link

@soc soc commented Nov 6, 2016

@njouanin Can you describe your needs? Can't your requirement be addressed by aliasing org.threeten.bp to java.time?

The README also provides information about the org.threeten.bp -> java.time migration.

@njouanin
Copy link

@njouanin njouanin commented Nov 7, 2016

I can/will do this for now.
In the long term, do you plan to merge your work in this repo ? I see a coherence in having "reference" implementation carried by the scala-js github organization.

@soc
Copy link

@soc soc commented Nov 7, 2016

@njouanin

I can/will do this for now.

Ok, let me know if you hit any issues!

In the long term, do you plan to merge your work in this repo?

No, as the implementation is intended to work on the JVM, on JS and on Native. Adding it to scala-js would be confusing to two thirds of the potential users.
Architecturally, I think it is desirable to have as many libraries as possible exist as cross-platform implementations, sharing as much code as possible, and not platform-specific silos, in which effort is needlessly duplicated.

@mkotsbak
Copy link

@mkotsbak mkotsbak commented Nov 7, 2016

Anyway, isn't there time to change the package names, or add a wrapper for the original packages?

@soc
Copy link

@soc soc commented Nov 7, 2016

@mkotsbak

isn't there time to change the package names

See https://github.com/soc/scala-java-time/issues/22. The idea is to make sure that we can run the tests on all platforms before the rename, because as soon as we change the package to java.time, testing on the JVM becomes much harder.

add a wrapper for the original packages

I think shipping the aliases with the package would make sense, but I'm not sure how that would interact with the java.time from the JDK, though. I'm not sure I can do this myself in the next months, so please feel free to send a PR!

@mkotsbak
Copy link

@mkotsbak mkotsbak commented Nov 7, 2016

Ok. Something similar to https://github.com/zoepepper/scalajs-jsjoda/tree/master/java-time-drop-in/src/main/scala/java But it looks like a lot of work...

@soc
Copy link

@soc soc commented Nov 7, 2016

@mkotsbak I think it could be automated quite easily with a bit of reflection or REPL :power-mode scripting.

@adamvoss
Copy link

@adamvoss adamvoss commented Dec 5, 2016

@cquiroz You appear to be still be putting work into Simon's implementation. Could you weigh in whether you are interested in taking ownership of it or whether people should look only to this repository going forward (assuming no one else comes along that wants to pick up code)?

A PR to the website should probably be made either to indicate its new location or to indicate its inactive state.

@cquiroz
Copy link

@cquiroz cquiroz commented Dec 5, 2016

@vossad01 I pretend to continue Simon's work on my own fork, there is not too much left to do, it would be a pity to waste it given how much is done on scala-java-time. I'll post an update to the scala-js site once I have something released for real

@njouanin
Copy link

@njouanin njouanin commented Dec 5, 2016

Hi, I've written some (a lot actually) classes in my own fork. May be you can have a look at it so we don't work in double.

@cquiroz
Copy link

@cquiroz cquiroz commented Dec 5, 2016

@njouanin There is no reason why there can't be multiple java.time implementations for Scala.js. The one on scala-java-time is probably heavier given that is ported from a java implementation, some people may prefer the scala-js-java-time implementation instead

@njouanin
Copy link

@njouanin njouanin commented Dec 5, 2016

Sorry, I didn't read your repo name correctly.

@mxl
Copy link

@mxl mxl commented Dec 13, 2016

What's the state of this project? Is it maintained?

@sjrd
Copy link
Member

@sjrd sjrd commented Dec 13, 2016

It's maintained, but it is not contributed to. Feel free to send PRs, and we'll review them.

@dzhagr
Copy link

@dzhagr dzhagr commented Feb 3, 2017

The java.time.Instant is marked as implemented, even though the parse method is not implemented. Is there another issue for the parse methods support, which I can follow? Didn't find anything except the one which is closed #10.

@alonsodomin
Copy link
Contributor

@alonsodomin alonsodomin commented Feb 4, 2017

Parse methods are not implemented in any of the classes yet as that requires some sort of locale support.

Probably you would be more interested in @cquiroz 's scala-java-time as it is already much more complete.

@dzhagr
Copy link

@dzhagr dzhagr commented Feb 4, 2017

@alonsodomin thanks

@civilizeddev
Copy link

@civilizeddev civilizeddev commented Jul 4, 2018

Thank you contributors.
I need LocalDateTime.

@joriscode
Copy link

@joriscode joriscode commented Nov 7, 2019

What is the status of this PR/ library? It seems there has been no activity whatsoever since at least a year. I am interested in LocalDateTime and ZonedDateTime and thought I could contribute.

@sjrd
Copy link
Member

@sjrd sjrd commented Nov 7, 2019

Take a look at https://github.com/cquiroz/scala-java-time instead of this library. Nobody contributes to scalajs-java-time anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.