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: https://github.com/soc/threetenbp/pull/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.