To use moment-timezone, you will need [email protected]+, moment-timezone.js, and the moment-timezone data.
For convenience, there are builds available on momentjs.com/timezone/ with all the zone data or a subset of the data.
moment-timezone-with-data.js is recommended for server environments (Node.js) and covers all years available.moment-timezone-with-data-10-year-range.js is recommend for most browser environments, covering +/- 5 years from the year published.moment-timezone-with-data-1970-2030.js covers a 60 year range, for those that need more data but not the larger file size of the full data file.If you use one of the above files, you still need moment.js, but you do not need moment-timezone.js because it is included.
npm install moment-timezone
In Node.js, all the data is preloaded. No additional code is needed for loading data.
var moment = require('moment-timezone');
moment().tz("America/Los_Angeles").format();
In ECMAScript native module format (or in TypeScript):
import moment from 'moment-timezone';
moment().tz("America/Los_Angeles").format();
Note: You don't need to require/import the base moment library as well. Moment Timezone will
automatically load and extend the moment module, then return the modified instance.
Package managers like npm and yarn can sometimes create situations where multiple versions of
moment are installed. Importing only from moment-timezone can help ensure that the same version
is used consistently.
See this comment on issue #982
for a much more detailed explanation, including steps to fix potential versioning problems.
// Unnecessary, can cause issues with package managers
import moment from 'moment';
import 'moment-timezone';
// Correct
import moment from 'moment-timezone';
The pre-built bundles are also included in the npm package, and can be loaded directly.
These allow you to import the library with a smaller subset of data.
import moment from 'moment-timezone/builds/moment-timezone-with-data-10-year-range.js'; // or .min.js
You can also import just the library without any preloaded data.
import moment from 'moment-timezone/moment-timezone.js'; // or .min.js
moment.tz.load(customData);
<script src="moment.js"></script>
<script src="moment-timezone-with-data.js"></script>
When using Moment Timezone in the browser, you will need to load the data as well as the library.
You can either use the prebuilt library and data files linked on the homepage or build a subset of the data yourself and load it.
moment().tz("America/Los_Angeles").format();
require.config({
paths: {
"moment": "path/to/moment"
}
});
define(["path/to/moment-timezone-with-data"], function (moment) {
moment().tz("America/Los_Angeles").format();
});
npm install moment-timezone
var moment = require('moment-timezone');
moment().tz("America/Los_Angeles").format();
Note: By default, webpack bundles all moment-timezone data (in moment-timezone 0.5.25, that’s over 900 KBs minified).
To strip out unwanted data and bundle only the zone and date range data you need,
add the moment-timezone-data-webpack-plugin package:
// webpack.config.js
const MomentTimezoneDataPlugin = require('moment-timezone-data-webpack-plugin');
const currentYear = new Date().getFullYear();
module.exports = {
plugins: [
// To include only specific zones, use the matchZones option
new MomentTimezoneDataPlugin({
matchZones: /^America/
}),
// To keep all zones but limit data to specific years, use the year range options
new MomentTimezoneDataPlugin({
startYear: currentYear - 5,
endYear: currentYear + 5,
}),
],
};
Alternatively, the pre-built bundles are also included in the npm package, and can
be loaded directly. See the Node.js section for more details.
Also see the primary Moment.js Webpack documentation for an example of how to reduce Moment’s bundled locale data. Together these techniques can significantly reduce the final bundle size (by over 1 MB minified, or 85 KB minified + gzipped).
There are two interfaces for using time zones with Moment.js.
moment.tz(..., String) does parsing in given time zone
It takes all the same arguments as the moment constructor, but uses the last argument as a time zone identifier:
var a = moment.tz("2013-11-18 11:55", "Asia/Taipei");
var b = moment.tz("2013-11-18 11:55", "America/Toronto");
a.format(); // 2013-11-18T11:55:00+08:00
b.format(); // 2013-11-18T11:55:00-05:00
a.utc().format(); // 2013-11-18T03:55Z
b.utc().format(); // 2013-11-18T16:55Z
Note that created moments have different UTC time because these moments were created in different time zones.
moment().tz(String) does converting to provided time zone
var a = moment.utc("2013-11-18 11:55").tz("Asia/Taipei");
var b = moment.utc("2013-11-18 11:55").tz("America/Toronto");
a.format(); // 2013-11-18T19:55:00+08:00
b.format(); // 2013-11-18T06:55:00-05:00
a.utc().format(); // 2013-11-18T11:55Z
b.utc().format(); // 2013-11-18T11:55Z
In this example, you first create moment.utc("2013-11-18 11:55") object in UTC, and then change its timezone to specified. This also works if you create the object in your default timezone: moment("2013-11-18 11:55").
Note that created moments have equal UTC time because these moments were created in a default timezone.
moment.tz(..., String);
The moment.tz constructor takes all the same arguments as the moment
constructor, but uses the last argument as a time zone identifier.
var a = moment.tz("2013-11-18 11:55", "America/Toronto");
var b = moment.tz("May 12th 2014 8PM", "MMM Do YYYY hA", "America/Toronto");
var c = moment.tz(1403454068850, "America/Toronto");
a.format(); // 2013-11-18T11:55:00-05:00
b.format(); // 2014-05-12T20:00:00-04:00
c.format(); // 2014-06-22T12:21:08-04:00
This constructor is DST aware, and will use the correct offset when parsing.
moment.tz("2013-12-01", "America/Los_Angeles").format(); // 2013-12-01T00:00:00-08:00
moment.tz("2013-06-01", "America/Los_Angeles").format(); // 2013-06-01T00:00:00-07:00
The offset is only taken into consideration when constructing with an array, string without offset, or object.
var arr = [2013, 5, 1],
str = "2013-12-01",
obj = { year : 2013, month : 5, day : 1 };
moment.tz(arr, "America/Los_Angeles").format(); // 2013-06-01T00:00:00-07:00
moment.tz(str, "America/Los_Angeles").format(); // 2013-12-01T00:00:00-08:00
moment.tz(obj, "America/Los_Angeles").format(); // 2013-06-01T00:00:00-07:00
moment.tz(arr, "America/New_York").format(); // 2013-06-01T00:00:00-04:00
moment.tz(str, "America/New_York").format(); // 2013-12-01T00:00:00-05:00
moment.tz(obj, "America/New_York").format(); // 2013-06-01T00:00:00-04:00
If the input string contains an offset, it is used instead for parsing. The parsed moment is then converted to the target zone.
var zone = "America/Los_Angeles";
moment.tz('2013-06-01T00:00:00', zone).format(); // 2013-06-01T00:00:00-07:00
moment.tz('2013-06-01T00:00:00-04:00', zone).format(); // 2013-05-31T21:00:00-07:00
moment.tz('2013-06-01T00:00:00+00:00', zone).format(); // 2013-05-31T17:00:00-07:00
Unix timestamps and Date objects refer to specific points in time, thus it doesn't
make sense to use the time zone offset when constructing. Using moment.tz(Number|Date, zone)
is functionally equivalent to moment(Number|Date).tz(zone).
var timestamp = 1403454068850,
date = new Date(timestamp);
moment.tz(timestamp, "America/Los_Angeles").format(); // 2014-06-22T09:21:08-07:00
moment(timestamp).tz("America/Los_Angeles").format(); // 2014-06-22T09:21:08-07:00
moment.tz(date, "America/Los_Angeles").format(); // 2014-06-22T09:21:08-07:00
moment(date).tz("America/Los_Angeles").format(); // 2014-06-22T09:21:08-07:00
Уou may specify a boolean right after format argument to use strict parsing. Strict parsing requires that the format and input match exactly, including delimeters.
moment.tz('It is 2012-05-25', 'YYYY-MM-DD', "America/Toronto").isValid(); // true
moment.tz('It is 2012-05-25', 'YYYY-MM-DD', true, "America/Toronto").isValid(); // false
moment.tz('2012-05-25', 'YYYY-MM-DD', true, "America/Toronto").isValid(); // true
moment.tz('2012-05.25', 'YYYY-MM-DD', true, "America/Toronto").isValid(); // false
Due to daylight saving time, there is a possibility that a time either does not exist, or has existed twice.
In the spring, at the start of DST, clocks move forward an hour. In reality though, it is not time that is moving, it is the offset moving.
Moving the offset forward gives the illusion that an hour has disappeared. As the
clock ticks, you can see it move from 1:58 to 1:59 to 3:00. It is easier to
see what is actually happening when you include the offset.
1:58 -5
1:59 -5
3:00 -4
3:01 -4
The result is that any time between 1:59:59 and 3:00:00 never actually happened.
Moment Timezone accounts for this. If you try to parse a time that never existed,
it will skip forward by the amount of the DST gap (usually 1 hour).
moment.tz("2012-03-11 01:59:59", "America/New_York").format() // 2012-03-11T01:59:59-05:00
moment.tz("2012-03-11 02:00:00", "America/New_York").format() // 2012-03-11T03:00:00-04:00
moment.tz("2012-03-11 02:59:59", "America/New_York").format() // 2012-03-11T03:59:59-04:00
moment.tz("2012-03-11 03:00:00", "America/New_York").format() // 2012-03-11T03:00:00-04:00
In this example, the two o'clock hour doesn't exist, so it is treated as equivalent to the three o'clock hour.
In the fall, at the end of DST, clocks move backward an hour. Again, time is not moving backwards, only the offset is. In this case, the illusion is that an hour repeats itself.
Again, it is easier to see what is actually happening when you include the offset.
1:58 -4
1:59 -4
1:00 -5
1:01 -5
Moment Timezone handles this by always using the earlier instance of a duplicated hour.
moment.tz("2012-11-04 00:59:59", "America/New_York"); // 2012-11-04T00:59:59-04:00
moment.tz("2012-11-04 01:00:00", "America/New_York"); // 2012-11-04T01:00:00-04:00
moment.tz("2012-11-04 01:59:59", "America/New_York"); // 2012-11-04T01:59:59-04:00
moment.tz("2012-11-04 02:00:00", "America/New_York"); // 2012-11-04T02:00:00-05:00
You won't be able to create a moment with the later instance of the duplicated hour unless you include the offset when parsing.
moment.tz("2012-11-04 01:00:00-04:00", "America/New_York"); // 2012-11-04T01:00:00-04:00
moment.tz("2012-11-04 01:00:00-05:00", "America/New_York"); // 2012-11-04T01:00:00-05:00
moment().tz(String);
moment().tz(String, Boolean);
The moment#tz mutator will change the time zone and update the offset.
moment("2013-11-18").tz("America/Toronto").format('Z'); // -05:00
moment("2013-11-18").tz("Europe/Berlin").format('Z'); // +01:00
This information is used consistently in other operations, like calculating the start of the day.
var m = moment.tz("2013-11-18 11:55", "America/Toronto");
m.format(); // 2013-11-18T11:55:00-05:00
m.startOf("day").format(); // 2013-11-18T00:00:00-05:00
m.tz("Europe/Berlin").format(); // 2013-11-18T06:00:00+01:00
m.startOf("day").format(); // 2013-11-18T00:00:00+01:00
Without any argument, moment#tz returns:
undefined if a time zone has not been set.var m = moment.tz("2013-11-18 11:55", "America/Toronto");
m.tz(); // America/Toronto
var m = moment.tz("2013-11-18 11:55");
m.tz() === undefined; // true
On passing a second parameter as true, only the timezone (and offset) is updated, keeping the local time same.
Consequently, it will now point to a different point in time if the offset has changed.
var m = moment.tz("2013-11-18 11:55", "America/Toronto");
m.format(); // 2013-11-18T11:55:00-05:00
m.tz('Europe/Berlin', true).format() // 2013-11-18T11:55:00+01:00
moment.tz(String).format("Z z"); // -08:00 PST
moment.tz(String).zoneAbbr(); // PST
moment.tz(String).zoneName(); // PST
In addition to including the +00:00 formatting information, Moment Timezone also
includes information for the abbreviated time zone name.
moment.tz([2012, 0], 'America/New_York').format('z'); // EST
moment.tz([2012, 5], 'America/New_York').format('z'); // EDT
moment.tz([2012, 0], 'America/Los_Angeles').format('z'); // PST
moment.tz([2012, 5], 'America/Los_Angeles').format('z'); // PDT
Note that these abbreviations may change depending on the time zone offset. This helps to distinguish offsets between places that may or may not use DST.
// Denver observes DST
moment.tz([2012, 0], 'America/Denver').format('Z z'); // -07:00 MST
moment.tz([2012, 5], 'America/Denver').format('Z z'); // -06:00 MDT
// Phoenix does not observe DST
moment.tz([2012, 0], 'America/Phoenix').format('Z z'); // -07:00 MST
moment.tz([2012, 5], 'America/Phoenix').format('Z z'); // -07:00 MST
Note also that these abbreviations are not globally unique. Below, you can see that both United States Central Standard Time and China Standard Time have the same abbreviation.
moment.tz('2016-01-01', 'America/Chicago').format('z'); // CST
moment.tz('2016-01-01', 'Asia/Shanghai').format('z'); // CST
You can also use moment#zoneAbbr to get the zone abbreviation. This is what
moment.js uses when formatting the z token.
moment.tz([2012, 0], 'America/New_York').zoneAbbr(); // EST
moment.tz([2012, 5], 'America/New_York').zoneAbbr(); // EDT
Moment.js also provides a hook for the long form time zone name. Because these strings are generally localized, Moment Timezone does not provide any long names for zones.
To provide long form names, you can override moment.fn.zoneName and use the zz token.
var abbrs = {
EST : 'Eastern Standard Time',
EDT : 'Eastern Daylight Time',
CST : 'Central Standard Time',
CDT : 'Central Daylight Time',
MST : 'Mountain Standard Time',
MDT : 'Mountain Daylight Time',
PST : 'Pacific Standard Time',
PDT : 'Pacific Daylight Time',
};
moment.fn.zoneName = function () {
var abbr = this.zoneAbbr();
return abbrs[abbr] || abbr;
};
moment.tz([2012, 0], 'America/New_York').format('zz'); // Eastern Standard Time
moment.tz([2012, 5], 'America/New_York').format('zz'); // Eastern Daylight Time
moment.tz([2012, 0], 'America/Los_Angeles').format('zz'); // Pacific Standard Time
moment.tz([2012, 5], 'America/Los_Angeles').format('zz'); // Pacific Daylight Time
Please note that the z formatting token will not always show the abbreviated time zone name, instead, will show the time offsets for each region.
moment.tz('America/Los_Angeles').format('z') // "PDT" (abbreviation)
moment.tz('Asia/Magadan').format('z') // "+11" (3-char offset)
moment.tz('Asia/Colombo').format('z') // "+0530" (5-char offset)
moment.tz.setDefault(String);
By default, moment objects are created in the local time zone.
The local time zone is determined by your JS environment such as a browser or server like Node.js.
To change the default time zone, use moment.tz.setDefault with a valid
time zone.
moment.tz.setDefault("America/New_York");
To reset the default time zone to local, use moment.tz.setDefault with no arguments.
moment.tz.setDefault();
This is a global setting (shared by all modules).
Subsequent calls to moment.tz.setDefault will not affect existing moment
objects or their clones.
moment.tz.guess();
moment.tz.guess(Boolean);
Moment Timezone uses the Internationalization API (Intl.DateTimeFormat().resolvedOptions().timeZone) in supported browsers to determine the user's time zone.
On other browsers, time zone detection is rather tricky to get right, as there is little information provided by those browsers. For those, it will use Date#getTimezoneOffset and Date#toString on a handful of moments around the current year to gather as much information about the browser environment as possible. It then compares that information with all the time zone data loaded and returns the closest match. In case of ties, the time zone with the city with largest population is returned.
By default Moment Timezone caches the detected timezone. This means that subsequent calls to moment.tz.guess() will always return the same value.
You can call moment.tz.guess() with an optional boolean argument "ignoreCache". If set to true, the cache will be ignored and overwritten with the new value.
moment.tz.guess(); // America/Chicago
// suppose the client's timezone changes to Europe/Berlin
moment.tz.guess(); // America/Chicago
moment.tz.guess(true); // Europe/Berlin
moment.tz.guess(); // Europe/Berlin
moment.tz.names(); // String[]
To get a list of all available time zone names, use moment.tz.names.
moment.tz.names(); // ["Africa/Abidjan", "Africa/Accra", "Africa/Addis_Ababa", ...]
moment.tz.zonesForCountry(String); // String[]
moment.tz.zonesForCountry(String, Boolean);
To get a list of time zones for some country, use moment.tz.zonesForCountry().
This takes an ISO 3166-1 two-letter country code.
moment.tz.zonesForCountry('US');
By default this method returns zone names sorted alphabetically:
["America/Adak", "America/Anchorage", ... "Pacific/Honolulu"]
To also get offsets, pass true as the 2nd parameter:
moment.tz.zonesForCountry('CN', true);
In this case, it returns an array of objects with the zone's name and its offset for the current date and time.
[
{ name: "Asia/Shanghai", offset: -480 },
{ name: "Asia/Urumqi", offset: -360 }
]
It's useful if you need to sort time zones by offset, but be aware that the offsets can change throughout the year.
All known country codes in the data can be retrieved using method moment.tz.countries().
Note: Sometimes these methods might return unexpected data. See the Countries and Zones guide for more details.
In order to match a timestamp to an offset, Moment Timezone uses a Zone object.
Though you shouldn't even need to use it, this object's constructor is available
on the moment.tz.Zone namespace.
This object has 5 properties.
{
name : 'America/Los_Angeles', // the unique identifier
abbrs : ['PDT', 'PST'], // the abbreviations
untils : [1414918800000, 1425808800000], // the timestamps in milliseconds
offsets : [420, 480], // the offsets in minutes
population : 15000000 // a rough population count for the largest city in this zone
}
zone.name; // America/Los_Angeles
The uniquely identifying name of the time zone. See the IANA Time Zone database naming guidelines for more details about the naming convention.
Note that the guidelines also say that these zone identifiers shouldn't be displayed directly to end users:
Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Czech Republic" instead of the timezone name
"Europe/Prague".
Providing a full list of translated zone names for every locale is outside the scope of Moment Timezone. The Unicode CLDR project contains locale-aware mappings for this purpose.
zone.abbr(timestamp); // PST
Get the abbreviation for a given timestamp (in milliseconds) from a Zone.
moment.tz.zone('America/Los_Angeles').abbr(1403465838805); // PDT
moment.tz.zone('America/Los_Angeles').abbr(1388563200000); // PST
zone.utcOffset(timestamp); // 480
Get the offset for a given timestamp (in milliseconds) from a Zone.
moment.tz.zone('America/Los_Angeles').utcOffset(1403465838805); // 420
moment.tz.zone('America/Los_Angeles').utcOffset(1388563200000); // 480
POSIX compatibility requires that the offsets are inverted. Therefore, Etc/GMT-X will have an offset of +X and Etc/GMT+X will have an offset of -X. This is a result of IANA's Time Zone Database and not an arbitrary choice by Moment.js. Thus, using locality based identifiers is preferred over fixed-offset identifiers.
This is also described on the Wikipedia entry for the database:
The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead of GMT).
For example, using the Europe/Madrid identifier gives a different result from Etc/GMT+1.
moment().tz('Etc/GMT+1').format('YYYY-MM-DD HH:mm ZZ');
// '2014-12-18 11:22 -0100'
moment().tz('Europe/Madrid').format('YYYY-MM-DD HH:mm ZZ');
// '2014-12-18 13:22 +0100'
zone.parse(timestamp); // 480
Parse an offset for a timestamp constructed from Date.UTC in that zone.
This is what Moment Timezone uses to parse input into a time zone. The process is conceptually similar to the following.
Assume we want to find the exact moment of March 19 2014 8:30 am in New York.
Because the offset varies between -04:00 and -05:00 in New York, we don't know
what the offset was on March 19th.
Instead, we create a timestamp in UTC and pass that to zone.parse, which will
return the offset at that time.
var zone = moment.tz.zone('America/New_York');
zone.parse(Date.UTC(2012, 2, 19, 8, 30)); // 240
This is the code that handles the cases referenced in the Parsing Ambiguities section above.
var zone = moment.tz.zone('America/New_York');
zone.parse(Date.UTC(2012, 2, 11, 1, 59)); // 300
zone.parse(Date.UTC(2012, 2, 11, 2, 0)); // 240
Moment Timezone uses two data formats. An unpacked version for calculations and a packed version for minified transport.
The unpacked format looks exactly like the zone object.
The data below is for Los Angeles between 2014 and 2018.
{
name : 'America/Los_Angeles',
abbrs : ['PST', 'PDT','PST', 'PDT', 'PST', 'PDT', 'PST', 'PDT', 'PST', 'PDT', 'PST'],
untils : [1394359200000, 1414918800000, 1425808800000, 1446368400000, 1457863200000, 1478422800000, 1489312800000, 1509872400000, 1520762400000, 1541322000000, null],
offsets : [480, 420, 480, 420, 480, 420, 480, 420, 480, 420, 480],
population : 15000000,
countries : ['US']
}
The lengths of abbrs, untils, offsets are all the same. The offset and abbr at
any index are only active while the timestamp is less than the until at that index.
An easy way to read this aloud is "between untils[n-1] and untils[n], the abbr should be abbrs[n] and
the offset should be offsets[n]".
Note that untils are measured in milliseconds and offsets are measured in minutes.
The packed format represents an unpacked zone in a single string.
The data below is for Los Angeles between 2014 and 2018. More time zones can be seen in the packed source file.
'America/Los_Angeles|PST PDT|80 70|01010101010|1Lzm0 1zb0 Op0 1zb0 Rd0 1zb0 Op0 1zb0 Op0 1zb0|15e6'
In order to save as many bytes as possible, we used a very compact format to store the data.
The data is split into 6 sections separated by pipes.
| # | Type | Example |
|---|---|---|
| 0 | Name | America/Los_Angeles |
| 1 | Abbr Map | PST PDT |
| 2 | Offset Map | 80 70 |
| 3 | Abbr/Offset Index | 01010101010 |
| 4 | Timestamp Diff | 1Lzm0 1zb0 Op0 1zb0 Rd0 1zb0 Op0 1zb0 Op0 1zb0 |
| 5 | Population | 15e6 |
Name: The canonical name of the time zone.
Abbr Map: A space separated list of all the abbreviations ever used in this time zone.
Offset Map: A space separated list of all the offsets ever used in this time zone in minutes in base 60.
Abbr/Offset Index: A tightly packed array of indices into the offset and abbr maps. These are also in base 60.
Timestamp Diffs: This is where the timestamps are stored.
Because we are dealing with a sorted list of timestamps, we just store the diff from the last timestamps rather than storing the full timestamps.
The first item in the array is a unix timestamp in minutes. All items after the first item are numbers of minutes to be added to the previous value during unpacking. All items are stored in base 60.
As you may have seen from the example above, the timestamp diffs tend to duplicate the same values from year to year. These duplications allow gzip to compress the data even further than if we used full timestamps.
Population: The rough population size of the city that the zone is named after.
This is not in base 60, but instead uses scientific exponential notation.
For example, a value of 15e6 means 15 * 10