Use Intl API for guessing when available #291
Conversation
mattjohnsonpint
force-pushed
the
tzguess
branch
from
49e4c66 to
2d0d3df
Compare
|
Perhaps an additional sanity check is required. Moment-timezone may have newer timezone info than the system due to the device vendor does not provide updates. That is why another timezone may be set by the user to get correct time offset. var mLocal = moment();
var mGuess = mLocal.clone().tz(zone);
if (mLocal.hours() === mGuess.hours() && mLocal.minutes() === mGuess.minutes()) {
return zone;
}Also I would suggest to add try-catch. |
|
Sorry, just realized that it is more complicated. After moment.tz.setDefault(...) my suggestion will not work. |
| // use Intl API when available and returning valid time zone | ||
| if (typeof Intl === 'object' && isFunction(Intl.DateTimeFormat)) { | ||
| var zone = Intl.DateTimeFormat().resolvedOptions().timeZone; | ||
| if (zone && (zone.indexOf("/") > -1 || zone === 'UTC')) { |
There was a problem hiding this comment.
How about something like if (typeof zone === 'string' && names[normalizeName(zone)]) { to make sure a identifier returned from Intl actually has data loaded? Maybe we could add a logError if Intl returns an identifier that was not loaded in the data set?
There was a problem hiding this comment.
Yes, I like that idea. I'll work on that.
Since the ECMA-402 Internationalization API provides a mechanism to get the current time zone, we should use it when available and fully implemented.
Note that we also need to guard against a few bad android implementations that return non-IANA time zone IDs. (jstzdetect ran into this)
This will address #290