Implement all java.time classes. #7

Open
nicolasstucki opened this Issue Feb 2, 2016 · 37 comments

Comments

Projects
None yet
@nicolasstucki
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@fedesilva

fedesilva 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

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

This comment has been minimized.

Show comment
Hide comment
@sjrd

sjrd Apr 11, 2016

Member

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

Member

sjrd commented Apr 11, 2016

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

@rpiaggio

This comment has been minimized.

Show comment
Hide comment
@rpiaggio

rpiaggio May 29, 2016

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

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

@sjrd

This comment has been minimized.

Show comment
Hide comment
@sjrd

sjrd May 29, 2016

Member

IANAL but yes.

Member

sjrd commented May 29, 2016

IANAL but yes.

@rpiaggio

This comment has been minimized.

Show comment
Hide comment
@rpiaggio

rpiaggio 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: soc/scala-java-time#22

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: soc/scala-java-time#22

@alonsodomin

This comment has been minimized.

Show comment
Hide comment
@alonsodomin

alonsodomin Jun 16, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mkotsbak

mkotsbak 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.

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

This comment has been minimized.

Show comment
Hide comment
@soc

soc 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.

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

This comment has been minimized.

Show comment
Hide comment
@mkotsbak

mkotsbak Jul 7, 2016

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

mkotsbak commented Jul 7, 2016

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

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc 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?).

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

This comment has been minimized.

Show comment
Hide comment
@alonsodomin

alonsodomin Jul 7, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@soc

soc 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.

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.

@ocadaruma ocadaruma referenced this issue in opt-tech/chronoscala Aug 15, 2016

Closed

support scala-js #5

@liorhar liorhar referenced this issue in getquill/quill Oct 7, 2016

Merged

encoder for java 8 LocalDate & LocalDateTime #583

6 of 6 tasks complete
@njouanin

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin 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 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

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin 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 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

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin 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.

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

This comment has been minimized.

Show comment
Hide comment
@soc

soc 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?

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

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin 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.

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

This comment has been minimized.

Show comment
Hide comment
@soc

soc 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.

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

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin 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.

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

This comment has been minimized.

Show comment
Hide comment
@soc

soc 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.

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

This comment has been minimized.

Show comment
Hide comment
@mkotsbak

mkotsbak Nov 7, 2016

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

mkotsbak commented Nov 7, 2016

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

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Nov 7, 2016

@mkotsbak

isn't there time to change the package names

See soc/scala-java-time#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!

soc commented Nov 7, 2016

@mkotsbak

isn't there time to change the package names

See soc/scala-java-time#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

This comment has been minimized.

Show comment
Hide comment
@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Nov 7, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@adamvoss

adamvoss 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.

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

This comment has been minimized.

Show comment
Hide comment
@cquiroz

cquiroz 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

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

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin 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.

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

This comment has been minimized.

Show comment
Hide comment
@cquiroz

cquiroz 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

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

This comment has been minimized.

Show comment
Hide comment
@njouanin

njouanin Dec 5, 2016

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

njouanin commented Dec 5, 2016

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

@mxl

This comment has been minimized.

Show comment
Hide comment
@mxl

mxl Dec 13, 2016

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

mxl commented Dec 13, 2016

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

@sjrd

This comment has been minimized.

Show comment
Hide comment
@sjrd

sjrd Dec 13, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@dzhagr

dzhagr 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.

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

This comment has been minimized.

Show comment
Hide comment
@alonsodomin

alonsodomin Feb 4, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment

dzhagr commented Feb 4, 2017

@alonsodomin thanks

@v6ak v6ak referenced this issue in v6ak/zbdb-stats Sep 15, 2017

Open

Zvážit náhradu za Moment.JS #2

@wenta wenta referenced this issue in carldata/timeseries Mar 16, 2018

Merged

Issue #62 #104

@civilizeddev

This comment has been minimized.

Show comment
Hide comment
@civilizeddev

civilizeddev Jul 4, 2018

Thank you contributors.
I need LocalDateTime.

Thank you contributors.
I need LocalDateTime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment