Implement timezone interface #3134
Conversation
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
If we merge this now, we'll break moment-timezone. So staging for v3 until we can figure out when to do them both together. |
See rebased version in #3807. |
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,
LocalTimeZone
andFixedOffsetTimeZone
. Libraries likemoment-timezone
could provide their ownTZDBTimeZone
class that implements the TimeZone interface.Each moment created now has a mandatory time zone. Calls to
moment()
would have aLocalTimeZone
instance, calls tomoment.utc()
would have aFixedOffsetTimeZone
instance, and calls tomoment.tz()
would have aTZDBTimeZone
instance.To support this, we will no longer be using the local timezone
Date.prototype
getters and setters. All calls to the underlying date object use thesetUTC*
andgetUTC*
methods, and parsing is done withDate.UTC()
. We will continue to store the_offset
property on a moment to determine what the offset is.Public API Additions
moment.withTimeZone(timeZone)
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
moment()
ormoment.utc()
.Private API Removals
moment.updateOffset
hook.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.
moment#_useUTC
This is used by the parser to determine whether to use
new Date(y, m, d...)
orDate.UTC(y, m, d)
when constructing theDate
. We are always usingDate.UTC(y, m, d)
, so this is no longer needed.moment#_isUTC
This was used to switch between calls to
Date#getMonth
andDate#getUTCMonth
, but we are always usingDate#getUTCMonth
, so this is unneeded.moment.momentProperties
This added for moment timezone to copy the
_z
property 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
moment#isLocal
,moment#isUtc
,moment#isUtcOffset
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'
.Open Questions
This adds
moment.withTimeZone
as 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.