Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document cross-language comparison #105

Open
littledan opened this issue Dec 30, 2018 · 25 comments
Open

Document cross-language comparison #105

littledan opened this issue Dec 30, 2018 · 25 comments

Comments

@littledan
Copy link
Member

littledan commented Dec 30, 2018

How does this proposal compare to date-time libraries in other programming languages, and to JavaScript date-time libraries in the ecosystem? I know many of the champions are familiar with a wide range of these things, and that the design here was based on this experience, but I don't see any documentation about that (and I'm curious).

@kaizhu256
Copy link
Contributor

kaizhu256 commented Dec 30, 2018

i would say a typical web-project has these common use-cases, listed in order of descending usage-frequency.

note:
utcISOString = canonical utc-ISOString, e.g. "2017‑12‑31T09:00:00.123Z"
localeISOString = canonical locale-ISOString, e.g. "2017‑12‑31T09:00:00.123+09:00"
ISOStringDate = canonical ISOStringDate, e.g. "2017‑12‑31"

  1. baton-passing

    • passing utcISOString between workflow-components, and client <-> server <-> db
  2. presentation-logic (to html, spreadsheet, pdf, logging, etc)

    • converting utcISOString -> localeISOString
    • getting day-of-week from ISOStringDate
    • getting week-of-month from ISOStringDate
  3. input-logic (from DOM-element, database, etc)

    • regexp validation-checking localeISOString
    • converting localeISOString -> utcISOString
  4. business-logic

    • datetime arithmetic on utcISOString
    • date arithmetic on ISOStringDate
    • getting day-of-week from ISOStringDate
    • getting week-of-month from ISOStringDate

from a web-project perspective, the current proposal is overkill as it focus too much on the [less-common] business-logic use-case. a better solution (for ease-of-use and debugging) is to use static-functions that play well with the [more-common] baton-passing use-case.

  1. baton-passing

    • no static-function needed for passing utcISOString
  2. presentation-logic (to html, spreadsheet, pdf, logging, etc)

    • Date.toLocaleISOString(utcISOString, timezoneOffset) -> localeISOString
    • Date.getDayOfWeek(ISOStringDate) -> number
    • Date.getWeekOfMonth(ISOStringDate) -> number
  3. input-logic (from DOM-element, database, etc)

    • no static-function needed for regexp validation-checking localeISOString
    • Date.toUTCISOString(localeISOString) -> utcISOString
  4. business-logic

    • Date.addToUTCISOString(utcISOString, interval) -> utcISOString
    • Date.addToISOStringDate(ISOStringDate, interval) -> ISOStringDate
    • Date.getDayOfWeek(ISOStringDate) -> number
    • Date.getWeekOfMonth(ISOStringDate) -> number

these static-functiosn are also easier to spec (and to optimize for the big-picture UX-workflow) than the current proposal.

@gilmoreorless
Copy link
Contributor

gilmoreorless commented Dec 30, 2018

@kaizhu256 that answer has nothing to do with the question asked. Please keep replies relevant instead of continually pushing your own agenda in every possible issue.

@ljharb
Copy link
Member

ljharb commented Dec 30, 2018

@kaizhu256 that doesn’t seem to answer the OP; namely, a comparison to other libraries and other languages. It seems Iike you’re talking about the overall design of the proposal. Perhaps you want to file a separate issue for that?

@motin
Copy link

motin commented Dec 30, 2018

+1 I'd love to see and contribute to comparisons here. Maybe start with a list of relevant libraries and programming languages?

JS:

Btw brief overview of the JS libraries above: https://github.com/you-dont-need/You-Dont-Need-Momentjs#brief-comparison

PHP:

Which others?

@phueper
Copy link

phueper commented Dec 30, 2018

there is Java which had the joda-time library that resulted in JSR-310 and became part of the language in Java 8

and there's an attempt to port that API to JS in the js-joda project (full disclosure : I'm one of the maintainers of that port)

@littledan
Copy link
Member Author

littledan commented Dec 30, 2018

@motin That would be great! Maybe you can start with a PR to the README with an initial comparison. I might add Java, Python and .NET date libraries (I have heard they settled on a similar design to this proposal, but don't know the details). From my perspective, the more data the better, especially if you can include some information about people's experience using the various interfaces, common pitfalls, etc., and draw some high level summaries/conclusions.

@kaizhu256 A comparison/upgrade guide for Date would be great as well, even if it's not what I was originally suggesting. It's important that we explain why the proposal here is to make a new set of types, rather than go with a date-fns-like approach.

@kaizhu256
Copy link
Contributor

kaizhu256 commented Dec 31, 2018

its been 7 years, but iirc as a python programmer, there was little use for python's date and time objects. i exclusively used datetime in python-programming (mostly financial programs).

currently contracted to work on a finance-related .net web-project with c# backend. from what i can tell about project:

  1. so far, there's no need for date business-logic in c# itself

    • all server-side date business-logic reside in sql-queries
  2. so far, the only date business-logic in javascript/frontend is sorting utcISOString's

  3. input-logic consists of creating timestamps and converting localISOString -> utcISOString

  4. presentation-logic consists of converting sql-queried utcISOString -> localISOString

  5. common use-case is baton-passing data-in-transit utcISOString between client <-> server <-> db

@maggiepint
Copy link
Member

maggiepint commented Jan 4, 2019

Absolutely happy to take a PR on this one. The most relevant comparisons are JodaTime, JS Date, Moment, C# DateTime and Python.

@Pauan
Copy link

Pauan commented Jan 5, 2019

Also possibly relevant: https://crates.io/crates/chrono

@littledan
Copy link
Member Author

littledan commented Jan 5, 2019

Btw some other interesting points of comparison would be the Windows datetime APIs, the POSIX/Linux/macOS ones, and the ICU Calendar/Date interfaces. Many JavaScript implementations will base their Temporal proposal on one or more of these, so it would be handy to lay out how it translates.

@rbuckton
Copy link

rbuckton commented Jan 10, 2019

@maggiepint: For C#/.NET, don't forget DateTimeOffset, TimeSpan, and TimeZoneInfo

@kaizhu256

This comment has been minimized.

@hawkrives

This comment has been minimized.

@kaizhu256

This comment has been minimized.

@ryzokuken
Copy link
Member

ryzokuken commented Jul 15, 2019

@littledan I think this is already been heavily discussed? Anyway, I don’t see anything actionable here for now, so I’m leaning towards closing this, but please feel free to reopen if you think something needs to be addressed.

@sffc
Copy link
Collaborator

sffc commented Jul 15, 2019

#139 is feedback relating to a C++ library.

I don't know of anything else actionable on this issue unless we wanted to solicit feedback from more library authors in other languages.

@ryzokuken
Copy link
Member

ryzokuken commented Jul 16, 2019

@sffc #144 is feedback from the author of the Java library and #103 is from Elm so I’d say we’re good?

@littledan
Copy link
Member Author

littledan commented Sep 11, 2019

I'm not sure why this was closed; I think it'd be good to write up a document comparing Temporal to other date APIs. I don't see any such document.

@littledan littledan reopened this Sep 11, 2019
@gibson042 gibson042 added the documentation label Sep 12, 2019
@jasonwilliams
Copy link
Member

jasonwilliams commented Jan 29, 2020

When Rust was in its early days and people started thinking what a dateTime library would look like they put together some research (including comparison with other languages), the document still exists and may be useful here:
https://github.com/rust-lang/rust-wiki-backup/blob/master/Lib-datetime.md

@ryzokuken ryzokuken added nice to have and removed documentation labels May 20, 2020
@ryzokuken ryzokuken changed the title Cross-language comparison Docuement cross-language comparison May 20, 2020
@ryzokuken ryzokuken changed the title Docuement cross-language comparison Document cross-language comparison May 20, 2020
@henryw374
Copy link

henryw374 commented Aug 1, 2020

Hey folks, I have done a comparison with java.time on my blog: http://widdindustries.com/ecma-temporal-vs-java-time/

It's not totally comprehensive, but should be a decent starting point for users of java.time or JSJoda. I'd welcome any feedback or corrections you have (including if If people feel there's potential for a PR in there).

@ptomato
Copy link
Collaborator

ptomato commented Aug 3, 2020

@henryw374: This is fantastic, thanks very much for doing it. We would welcome any PR on this topic that you think would be appropriate!

Some notes that occurred to me while reading it:

  • Temporal indeed doesn't have the equivalent of java.time.DateTimeFormatter, but I believe Intl.DateTimeFormat fulfills this role.
  • I wasn't aware of the distinction between java.time.Period and java.time.Duration. There is extensive discussion of how we solve this in Temporal in Proposed Temporal changes required to adopt RFC 5545 (iCalendar) meaning of durations #759. The short explanation is that there is an RFC about it (RFC 5545) which we decided to follow.
  • The "find out that the day starts at 1 AM" example in Temporal: Temporal.DateTime.from('2015-10-18T00:00').toAbsolute('America/Sao_Paulo').toDateTime('America/Sao_Paulo'). This is quite un-obvious and would be a motivation to add some start-of-day type of method to our zoned date-time type when it lands. (Easier "midnight" ? #737)
  • In Limit Absolute math to hours or smaller units (no days) ? #802 we are considering to stop treating days as 24 hours in the context of Temporal.Absolute.

@henryw374
Copy link

henryw374 commented Aug 4, 2020

Thanks for the feedback & links! I'll update the post with the relevant bits.

Re: Intl.DateTimeFormatter - As far as I can see it doesn't have a function to parse string patterns of user's making into Temporal objects, in the same way that java.time.DateTimeFormatter does. I may be wrong though? mentioned this in #796

@ryzokuken
Copy link
Member

ryzokuken commented Aug 4, 2020

Parsing is something we are considering in Temporal, Intl.DateTimeFormat is expect to be (and remain) a locale-aware formatter.

@ptomato
Copy link
Collaborator

ptomato commented Aug 4, 2020

Ah, I did not realize that java.time.DateTimeFormatter worked in both directions. Thanks for the correction.

@sffc
Copy link
Collaborator

sffc commented Aug 4, 2020

java.time.DateTimeFormatter doesn't always do the right thing for i18n; internally at Google we have our own alternative that we recommend for first party products, and it may be proposed publicly.

I wasn't aware of the distinction between java.time.Period and java.time.Duration

@justingrant has brought this up before in the context of our Duration discussions. We settled on 5545 instead of separate types.

@ptomato ptomato added this to the Stage 4 milestone Feb 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests