This is the initial pass at implementing moment/moment-rfcs#1
This introduces an interface for a TimeZone in moment core. Moment would provide 2 classes that implement the TimeZone interface,
Each moment created now has a mandatory time zone. Calls to
To support this, we will no longer be using the local timezone
Public API Additions
This is the public api for moment-timezone and other libraries to construct a moment in a timezone. It returns a function that can be used just like
var create = moment.withTimeZone(chicagoTimeZone); var nowInChicago = create(); var decemberInChicago = create("2016 décembre", "YYYY MMMM", "fr");
Private API Removals
This was build as an undocumented api for use by moment-timezone. We are moving the code for manually adjusting the offset into moment, so there is no need for an external library to handle this logic.
This is used by the parser to determine whether to use
This was used to switch between calls to
This added for moment timezone to copy the
Public API Deprecations
These methods don't really match the semantics of the new timezone interface. They were added because we had internal flags that toggled between different modes. A better interface would be something like
So, I think this interface should be
someTZ.parse(_d.getUTCFullYear(), _d.getUTCMonth(), ...)
and then this thing just does:
return getTimezoneOffset(new Date(year, month, day, hour, minute, second, millisecond))
That also saves you one date creation, which is nice.
For the local timezone, it is easier to use the date parts (year, month, day...) to calculate an offset, but for moment timezone, it is easier to use a UTC timestamp. I'll update the RFC and then this PR with a better api for parsing one of the two.
I do agree that this un-offset timestamp is confusing to explain...I'll try to describe it better in the RFC
You know what, I'm putting a release tag on this. We can't sit on it forever, it's a positive change, and those who patched private variables on a library can learn.