Suggestions for v2.0

These are ideas for potential breaking changes that could be introduced in v2.0, all open for discussion.

1. Settings.setDefaultZone instead of Settings.defaultZone setter since input type differs from getter
2. IANAZone constructor made private, use create() instead to benefit from the cache
3. Rename Zone.universal to isUniversal
4. New DateTime.now() method equivalent to local with no parameter
5. Rename options.setZone to keepZone in DateTime constructors’ options
6. Add a new DateTime.plus/minus(12, 'hours') method
7. Deprecate plus/minus(ms), i.e. a number parameter which has no obvious meaning when reading the code
8. In DateTime, resolvedLocaleOpts, toLocaleString and toLocaleParts all accept an options parameter which is a union of LocaleOptions (i.e. { locale, outputCalendar, numberingSystem } already used in reconfigure and toFormat) and Intl.DateTimeFormatOptions. These could be split into two options parameters instead, each with a different role
9. DateTime::resolvedLocaleOpts returns an { locale, outputCalendar, numberingSystem } object, whereas Intl.ResolvedDateTimeFormatOptions returns { locale, calendar, numberingSystem (and more) }. outputCalendar could be renamed to calendar instead to be more consistent.
10. Rename DateTime::resolvedLocaleOpts to resolvedLocaleOptions
11. DateTime.toSeconds returns an integer value (see #565), so that it can be used in Unix timestamps creation, and can otherwise be replaced by toMillis() / 1000

[GillesDebunne]

Thoughts:

2 I though this came from the 2.0 branch. I cannot remember why I did it in my branch, although it seems reasonable. I think all I did was to update the tests (24 occurrences) to use create instead of new

5 I agree the name should be more explicit. The impact of an undefined zone is also not obvious. The examples should show the results of these different options

6 Since I believe 90% of the case apply a single unit, this version seems more readable as an English sentence. At least that’s what I wrote first before looking at the documentation.

9 makes sense

11 toUnix feels too specific, and the timestamp precision seems to depend on the file system. What about asSeconds, which indicates a conversion? toSeconds could be deprecated to reduce the footprint.

[jpike88]

I’ve opened a PR to add another function for whole number unix timestamps, it uses the same Math.floor method as Moment.

#1114