[jasonkillian]

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/

[1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-...

[2]: https://www.threeten.org/

[3]: https://github.com/tc39/proposal-temporal/issues/707

[TheCoelacanth]

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

[eropple]

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]

I assume it doesn't help that Oracle is arguing in court that APIs should be copyrightable.

[salmonellaeater]

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/

[needusername]

Well they actively ignored his input:

https://github.com/tc39/proposal-temporal/issues/7

https://github.com/tc39/proposal-temporal/issues/84#issuecom...

[leothekim]

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

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

[2] https://www.joda.org/joda-time/apidocs/index.html

[shadowmatter]

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/Readabl...

[2] https://docs.oracle.com/javase/8/docs/api/java/time/Instant....

[foepys]

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]

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

[ryzokuken]

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

[Ndymium]

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

[jasonkillian]

It's a current WIP idea for the spec: 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]

I think he's referring to https://github.com/tc39/proposal-temporal/issues/707.

[benatkin]

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]

It has a date/time class that doesn't include a timezone too...