Proposal-temporal: Feedback from my attempt to utilize the current API

[thefliik]

_This issue is copied over from the temporal polyfil repo_

Hi there,

I maintain a javascript recurring dates/schedule library, rSchedule, which happens to be date library agnostic (i.e. it supports moment, luxon, js-joda, and standard Date). For fun, I decided to try implementing a date adapter for the temporal polyfill and running it against my tests. Eventually I realized that the version of this polyfill on NPM is pretty behind the version in this repo. That alone would have stopped my experiment.

Even basing my implementation of the current temporal API though, I ended up giving up when it became apparent that I was going to need to do more work than I realized. A few usability issues with the current API:

• Can't simply call new CivilDateTime() / new ZonedDateTime()/ etc like new Date() to get an object with the current local clock's values (and current timezone, if applicable).
  
  
  
  • The lack of this functionality proved incredibly annoying
  
  
• Neither CivilDateTime nor ZonedDateTime have a fromObject() static method to simplify the creation of new CivilDateTime / ZonedDateTime.
  
  
  
  • e.g. can't do ZonedDateTime.fromObject({year: 2019, month: 10, day: 10, timeZone: 'America/Los_Angeles'}) (units not provided would default to 0, or 1 in the case of month/day)
  
  
  • Sticking with the conventions established in the spec, perhaps the method should be called ZonedDateTime.with() rather than ZonedDateTime.fromObject().
  
  
• Nothing like Date#toISOString() on ZonedDateTime to see what the value looks like as a string in UTC.
  
  
  
  • I've never had a production use case for toISOString(), but in development I often find it quite handy.
  
  
• Ability to get the length of the current month (for DateLike objects).
  
  
  
  • e.g. new CivilDate(2010, 10, 1).lengthOfMonth === 31
  
  
• Lack of a ZonedDateTime.prototype.set(arg: DateTimeLike) method .with() does this
  
  
  
  • I created a separate issue for this
  
  

Also another annoyance which may not be universally applicable, but in my case I'm using both CivilDateTime and ZonedDateTime together. Having ZonedDateTime implement getCivilDateTime() but not having CivilDateTime implement it means that I need to check what type of object I'm dealing with, rather than simply call date.getCivilDateTime() and know that I've got a CivilDateTime.

In general, I think the API could be improved by normalizing the interfaces between objects, even when that means CivilDateTime#getCivilDateTime() simply returns the same object. Not sure if this will be a feeling others share though.

[pipobscure]

I'm closing this since it's being documented in #154 and reflected in the current polyfill.

THANKS!

[Offirmo]

I'm strongly seconding @thefliik 's feedback about

can't do ZonedDateTime.fromObject({year: 2019, month: 10, day: 10, timeZone: 'America/Los_Angeles'})

Is it captured in #154 ? Couldn't find it.

[ptomato]

The method was named fromObject() at the time, but now it's just from(), this should work: Temporal.ZonedDateTime.from({year: 2019, month: 10, day: 10, timeZone: 'America/Los_Angeles'})