6 ms·

I think this is a great proposal and a huge step in the right direction for JS. I am curious though, is there a reason not to just essentially duplicate the Jod

I think this is a great proposal and a huge step in the right direction for JS. I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API? As far as I understand, they are generally considered a gold standard as far as datetime APIs. Is it too Java-y that it wouldn't make sense to port to JS? Are there copyright implications? The JS Temporal proposal _does_ as far as I can tell, share many of the underlying fundamental concepts, which is great, but then confusingly has some types, such as `LocalDateTime`, which mean the exact opposite of what they do in the well-known Java API [3]. There is still discussion going on about these details, but from my perspective it seems like the best thing would be to just copy the Java naming conventions exactly. [0]: https://www.joda.org/joda-time/ https://www.joda.org/joda-time/ [1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/package-... [2]: https://www.threeten.org/ https://www.threeten.org/ [3]: https://github.com/tc39/proposal-temporal/issues/707 https://github.com/tc39/proposal-temporal/issues/707

Ndymium 6y ago
> The JS Temporal proposal _does_ as far as I can tell, share many of the underlying fundamental concepts, which is great, but then confusingly has some types, such as `LocalDateTime` I can't find a mention of LocalDateTime in the Temporal docs, did you mean something else?
- leothekim 6y ago
  I think he's referring to https://github.com/tc39/proposal-temporal/issues/707 https://github.com/tc39/proposal-temporal/issues/707.
- jasonkillian 6y ago
  It's a current WIP idea for the spec: https://github.com/tc39/proposal-temporal/pull/700 https://github.com/tc39/proposal-temporal/pull/700 Figuring out a name is still part of the ongoing discussion, so this specific case of `LocalDateTime` isn't a huge deal, and I might have misrepresented things slightly in my original comment, sorry! But I do think the overall point still stands - that it might be best to just use the same names and terminology as Java does.
leothekim 6y ago
+1 to going off of Joda API. This is a very well-thought out datetime API with a fluent interface for building date/time objects in an immutable way. Just doing this would be a huge step improvement for JS.
- bxparks 6y ago
  I find that the Java 8 java.time API [1] easier to understand than Joda Time [2] when working with timezones. In particular, the OffsetDateTime and ZonedDateTime classes in java.time seem well-designed and easy to use. The equivalents in Joda Time are harder for me. [1] https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/package-... [2] https://www.joda.org/joda-time/apidocs/index.html https://www.joda.org/joda-time/apidocs/index.html
  - foepys 6y ago
    Considering that JodaTime was more or less the reference for java.time, I would be very disappointed if java.time was worse and didn't get rid of JodaTime's design flaws.
    - masklinn 6y ago
      > Considering that JodaTime was more or less the reference for java.time It would probably be more correct to say that java.time is Joda version 2. Colebourne, the original author of Joda, was also one of the leads on JSR-310, and very much intended that 310 learn from the mistakes on Joda.
  - shadowmatter 6y ago
    Agreed. Joda had the right abstractions (instants, durations, etc) but the class hierarchy for them was unnecessarily complex. A lot of this complexity comes from opting for the abstractions to be either mutable or immutable. For example, `ReadableInstant` [1] in Joda implements 3 interfaces and has 7 subclasses. And really, what is the difference between `AbstractDateTime` and `BaseDateTime`? Whereas `Instant` from java.time [2] is an immutable value type and I haven't found it lacking in any respect. On the whole java.time has struck me as extremely well designed (after coming from Python and previous date and time libraries in Java) and I think it would behoove other languages to liberally copy its design. [1] https://www.joda.org/joda-time/apidocs/org/joda/time/ReadableInstant.html https://www.joda.org/joda-time/apidocs/org/joda/time/Readabl... [2] https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html https://docs.oracle.com/javase/8/docs/api/java/time/Instant....
TheCoelacanth 6y ago
This. They already copied the crappy date API from Java. Why not copy the good one too?
- eropple 6y ago
  I don't usually laugh at HN comments, but this is pretty good. And it's true. Joda-Time and its near relatives are just genuinely good. So much effort has gone into addressing so many edge and corner cases that it seems like a shame to not just tuck all that work under one's arm and steal it.
- needusername 6y ago
  I assume it doesn't help that Oracle is arguing in court that APIs should be copyrightable.
ryzokuken 6y ago
> I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API? They're definitely an influence, just not the only one. > LocalDateTime That's a strawman proposal that's essentially user feedback and not a part of the API. Not yet atleast.
benatkin 6y ago
Joda Time, like Python's datetime and a lot of other date/time libraries, has a date/time class that includes a timezone. Temporal keeps that separate. I think it's a different enough design that Joda Time's popularity isn't enough of a justification for adopting its API.
- stickfigure 6y ago
  It has a date/time class that doesn't include a timezone too...
salmonellaeater 6y ago
There is already a JS port of Joda[1] which works well and, crucially, uses all the same names and concepts. Could we just replace the Temporal proposal with this and save a lot of work and confusion? [1] https://js-joda.github.io/js-joda/ https://js-joda.github.io/js-joda/
needusername 6y ago
Well they actively ignored his input: https://github.com/tc39/proposal-temporal/issues/7 https://github.com/tc39/proposal-temporal/issues/7 https://github.com/tc39/proposal-temporal/issues/84#issuecomment-428315375 https://github.com/tc39/proposal-temporal/issues/84#issuecom...

Ndymium 6y ago

> The JS Temporal proposal _does_ as far as I can tell, share many of the underlying fundamental concepts, which is great, but then confusingly has some types, such as `LocalDateTime` I can't find a mention of LocalDateTime in the Temporal docs, did you mean something else?

leothekim 6y ago
I think he's referring to https://github.com/tc39/proposal-temporal/issues/707 https://github.com/tc39/proposal-temporal/issues/707.
jasonkillian 6y ago
It's a current WIP idea for the spec: https://github.com/tc39/proposal-temporal/pull/700 https://github.com/tc39/proposal-temporal/pull/700 Figuring out a name is still part of the ongoing discussion, so this specific case of `LocalDateTime` isn't a huge deal, and I might have misrepresented things slightly in my original comment, sorry! But I do think the overall point still stands - that it might be best to just use the same names and terminology as Java does.

leothekim 6y ago

+1 to going off of Joda API. This is a very well-thought out datetime API with a fluent interface for building date/time objects in an immutable way. Just doing this would be a huge step improvement for JS.

bxparks 6y ago
I find that the Java 8 java.time API [1] easier to understand than Joda Time [2] when working with timezones. In particular, the OffsetDateTime and ZonedDateTime classes in java.time seem well-designed and easy to use. The equivalents in Joda Time are harder for me. [1] https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/package-... [2] https://www.joda.org/joda-time/apidocs/index.html https://www.joda.org/joda-time/apidocs/index.html
- foepys 6y ago
  Considering that JodaTime was more or less the reference for java.time, I would be very disappointed if java.time was worse and didn't get rid of JodaTime's design flaws.
  - masklinn 6y ago
    > Considering that JodaTime was more or less the reference for java.time It would probably be more correct to say that java.time is Joda version 2. Colebourne, the original author of Joda, was also one of the leads on JSR-310, and very much intended that 310 learn from the mistakes on Joda.
- shadowmatter 6y ago
  Agreed. Joda had the right abstractions (instants, durations, etc) but the class hierarchy for them was unnecessarily complex. A lot of this complexity comes from opting for the abstractions to be either mutable or immutable. For example, `ReadableInstant` [1] in Joda implements 3 interfaces and has 7 subclasses. And really, what is the difference between `AbstractDateTime` and `BaseDateTime`? Whereas `Instant` from java.time [2] is an immutable value type and I haven't found it lacking in any respect. On the whole java.time has struck me as extremely well designed (after coming from Python and previous date and time libraries in Java) and I think it would behoove other languages to liberally copy its design. [1] https://www.joda.org/joda-time/apidocs/org/joda/time/ReadableInstant.html https://www.joda.org/joda-time/apidocs/org/joda/time/Readabl... [2] https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html https://docs.oracle.com/javase/8/docs/api/java/time/Instant....

TheCoelacanth 6y ago

This. They already copied the crappy date API from Java. Why not copy the good one too?

eropple 6y ago
I don't usually laugh at HN comments, but this is pretty good. And it's true. Joda-Time and its near relatives are just genuinely good. So much effort has gone into addressing so many edge and corner cases that it seems like a shame to not just tuck all that work under one's arm and steal it.
needusername 6y ago
I assume it doesn't help that Oracle is arguing in court that APIs should be copyrightable.

ryzokuken 6y ago

> I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API? They're definitely an influence, just not the only one. > LocalDateTime That's a strawman proposal that's essentially user feedback and not a part of the API. Not yet atleast.

benatkin 6y ago

Joda Time, like Python's datetime and a lot of other date/time libraries, has a date/time class that includes a timezone. Temporal keeps that separate. I think it's a different enough design that Joda Time's popularity isn't enough of a justification for adopting its API.

stickfigure 6y ago
It has a date/time class that doesn't include a timezone too...

salmonellaeater 6y ago

There is already a JS port of Joda[1] which works well and, crucially, uses all the same names and concepts. Could we just replace the Temporal proposal with this and save a lot of work and confusion? [1] https://js-joda.github.io/js-joda/ https://js-joda.github.io/js-joda/

needusername 6y ago

Well they actively ignored his input: https://github.com/tc39/proposal-temporal/issues/7 https://github.com/tc39/proposal-temporal/issues/7 https://github.com/tc39/proposal-temporal/issues/84#issuecomment-428315375 https://github.com/tc39/proposal-temporal/issues/84#issuecom...