Implement all java.time classes.

[nicolasstucki]

• 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]

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]

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

[rpiaggio]

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

[sjrd]

IANAL but yes.

[rpiaggio]

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]

@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]

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]

@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]

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

[soc]

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]

@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]

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]

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 ?

[soc]

@njouanin Instant.parse is already implemented here: https://github.com/soc/scala-java-time/blob/master/shared/src/main/scala/org/threeten/bp/Instant.scala#L216

[njouanin]

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.

[soc]

but it need DateTimeFormatter and DateTimeFormatBuilder which are not implemented currently

https://github.com/soc/scala-java-time/blob/master/shared/src/main/scala/org/threeten/bp/format/DateTimeFormatter.scala
https://github.com/soc/scala-java-time/blob/master/shared/src/main/scala/org/threeten/bp/format/DateTimeFormatterBuilder.scala

[njouanin]

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]

@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]

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]

@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]

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]

@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]

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

[soc]

@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]

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]

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

[adamvoss]

@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]

@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]

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]

@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]

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

[mxl]

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

[sjrd]

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

[dzhagr]

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]

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]

@alonsodomin thanks

[civilizeddev]

Thank you contributors.
I need LocalDateTime.

[joriscode]

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]

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

[joriscode]

I suggest to clarify the status of this project in its README

[Sciss]

Thanks for the library; It would be great to address the missing LocalDateTime which is very useful for logging. In any case, I think https://www.scala-js.org/libraries/libs.html should be updated to reflect if either of the libraries there is abandoned. P.S. Seems I mixed up scala-java-time and scala-java-locales (the latter being just a work in progress).

[soc]

@cquiroz #7 (comment)

[sjrd]

I suggest to clarify the status of this project in its README

This is now done.

I will close this issue now, since I don't think anything more will happen here.