/ moment Public
Implement timezone interface #3134
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
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,
FixedOffsetTimeZone. Libraries like
moment-timezonecould provide their own
TZDBTimeZoneclass that implements the TimeZone interface.
Each moment created now has a mandatory time zone. Calls to
moment()would have a
LocalTimeZoneinstance, calls to
moment.utc()would have a
FixedOffsetTimeZoneinstance, and calls to
moment.tz()would have a
To support this, we will no longer be using the local timezone
Date.prototypegetters and setters. All calls to the underlying date object use the
getUTC*methods, and parsing is done with
Date.UTC(). We will continue to store the
_offsetproperty on a moment to determine what the offset is.
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
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
new Date(y, m, d...)or
Date.UTC(y, m, d)when constructing the
Date. We are always using
Date.UTC(y, m, d), so this is no longer needed.
This was used to switch between calls to
Date#getUTCMonth, but we are always using
Date#getUTCMonth, so this is unneeded.
This added for moment timezone to copy the
_zproperty when cloning a moment, but now that timezones are a core concept for moment, a moment-timezone moment will behave the same as all other moments.
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
moment#timezone() === 'local'.
moment.withTimeZoneas partial application for the timezone, should we expand that to format, locale, and strict parsing?
Should we add a getter/setter for timezones? Should it publicly reference timezones with strings instead of objects?
To support this, we could provide an api to register callbacks to be used to resolve the timezone string.
The timezone resolver would just loop through all the callbacks, returning the first timezone that matched.