construct moment in zone #11

mj1856 opened this Issue Jul 8, 2013 · 28 comments
Moment.js member

This creates the moment in local time:


This creates the moment in UTC:


So I would expect to be able to create a moment in a particular zone with:"America/New_York","2013-01-01T00:00:00")

That gives an error, so I tried this:"2013-01-01T00:00:00", "America/New_York")

And it works, but gives a result of 2013-01-01T02:00:00-05:00. I would expect 2013-01-01T00:00:00-05:00.

I think it is assuming the input value is in my local offset (-07:00) and then converting it to the time zone specified.

All together, I'd expect to be able to convert from time zone A to time zone B like this:"2013-01-01T00:00:00","America/New_York").tz("America/Los_Angeles").format()

Also - we need a way to deal with ambiguous or invalid input times.


This would make moment/moment-timezone very feature complete in my eyes. Converting local times is tricky with regard to invalid/ambiguous times.

This is the pytz implementation for localize:

Here are some tests for localize() which would probably be very useful when implementing this:

What would the best API be? I think that something like this would make sense look the same as moment.utc()'Europe/Stockholm', '2013-01-01T00:00:00')
moment.local('Europe/Stockholm', '2013-01-01T00:00:00')
moment.localize('Europe/Stockholm', '2013-01-01T00:00:00')

This would be huge. I find myself much more often receiving dates with a known timezone that I want to store in a universal zone like UTC so that I can do safe date comparisons. Because UTC offsets can be different at different times of the year, I was hoping that this library would solve the problem with vanilla moment, which requires I know the current offset. I know the data must be there to solve this.

Moment.js member

There is a naive wrapper method already., zoneName);, format, zoneName);, format, language, zoneName);

However, that assumes that the offset has been provided in the input string already.

I agree, this is a good addition, but I don't know how soon I would be able to get to this. Pull requests welcome!


+1, a fix that parses ambiguous local strings arbitrarily is good enough for me


Another test case:[2010, 6, 10, 0, 0, 0], 'America/New_York').format()

yields '2010-07-10T03:00:00-04:00' when computer local time is 'America/Los_Angeles'. The array constructor is never ambiguous.


We also would love to see this feature added. Currently we have to work around it using something like this:

function toMomentInTimezone(sourceMoment, timezone) {
  var result =;
  return result;

I currently parse dates in various timezones like this:

var timezone = 'America/Los_Angeles';
var offset = ' '+moment().tz('Z');
moment('09/13/2013'+offset, 'MM/DD/YYYY Z').tz(timezone).format();

A shortcut moment method would be nice.

Moment.js member

@alanhamlett - the problem there is you are assuming that the current offset is the same as the offset that applies to the date you provided. If you execute this today for an input like 01/01/2013, it will still give you -07:00 when it should be -08:00.

Passing the local date/time to the first call might sound like a workaround, but there you would be affected by the time zone rules of your local computer. If I'm in Los Angeles, it's all fine. But if I'm running the same code from somewhere else, and the input falls near either my own daylight saving time transitions, or the Los Angeles daylight saving time transition, then the results could be wrong again.

@marcphilipp - your implementation makes a similar mistake.


Ah so this was handled in #25?


@neverfox Yea looks like #25 fixes it. For the "reverse" case your talking about (getting a user's olson timezone string) this library does that:


@mj1856 you're right, i shouldn't assume the current offset would be valid for a different date. Does #25 fix this?

Moment.js member

@alanhamlett - Yes, mostly . You'll need the latest develop from github, as it's not been released yet.

Tim raised some points in #27. I don't think it's completely done yet, but it is better.


Another option is allow set() to take the same arguments as the constructor. like moment().tz('America/New_York').set([2013, 10, 7]);


It's difficult to see where things are at, given the above, but my expectation from reading the Moment Timezone documentation is that I should be able to say:'20140310 23:40','YYYYMMDD HH:mm','America/Los_Angeles') and have that time returned with the timezone offset set correctly for Los Angeles at that date.


so again, is there a way to have moment instance in a given timezone, and not a shifted date ?

meaning, e.g.:"2013-11-18 11:55", "America/Toronto").unix() and"2013-11-18 11:55", "Europe/Berlin").unix() to have different values (with current implementation these two instances point to the same moment, meaning have equal timestamps).

Currently it is only achievable via trick suggested here:
#11 (comment)


@vgrigory @r-barnes When I run your statements, I get the expect results. So it appears to work correctly. I installed it from npm so it seems to be released. Not sure why this issue is still marked "Open," if that's the case.


yep, in v0.05 this is fixed

@marcphilipp marcphilipp referenced this issue in softwerkskammer/Agora May 29, 2014

Upgrade to moment-timezone-0.0.6 #712

Moment.js member

This should be solved including all edge cases around DST in #93.

@timrwood timrwood closed this Jun 18, 2014
@timrwood timrwood added this to the 0.1.0 milestone Jun 18, 2014

This still appears to be an issue in some cases - on the website, I get the following results:"2002-9-28 11:55", "Europe/Berlin").unix()
1033228500"2002-9-28 11:55", "America/Los_Angeles").unix()
Moment.js member

@froodian, you should have also seen the deprecation warning on parsing a string, no?

See the 'Supported ISO 8601 strings' section at, all those rules apply to, ZoneName) as well.

Adding a 0 before the 9 in the month will make it a valid ISO-8601 string, thus it will parse correctly."2002-09-28 11:55", "Europe/Berlin").unix()       // 1033206900"2002-09-28 11:55", "America/Los_Angeles").unix() // 1033239300

I see, thanks for the context. I must have missed that warning because it only shows up the first time on a given page.


How about supporting parsers?'Tuesday 9:00PM', 'dddd hh:mm', 'America/Los_Angeles')

I don't think this works currently

Moment.js member

@contra - It's supported. It's in the documentation actually:

var b ="May 12th 2014 8PM", "MMM Do YYYY hA", "America/Toronto");

I think the problem is just that your format string doesn't match the input. Try 'dddd h:mmA'


This looks like a bug:'03/06/2015', 'America/Los_Angeles').format();

The day of month is parsed as 05 when it should be 06.

It only works correctly in the last case:'2015/03/06', 'America/Los_Angeles').format();
"2015-03-05T16:00:00-08:00"'03-06-2015', 'America/Los_Angeles').format();
"2015-03-05T16:00:00-08:00"'2015-03-06', 'America/Los_Angeles').format();

Nevermind, specifying a format string fixes it:'03/06/2015', 'MM/DD/YYYY', 'America/Los_Angeles').format();


To convert a UTC date string to a specified timezone in a formatted manner, I tried the below:"2016-04-11T03:07:06.000+0000", "MMM DD YYYY hh:mm:ssA", "Europe/Berlin").format()

But the result was:
"Invalid date"

How come!!! As, new Date("2016-04-11T03:07:06.000+0000") returns Mon Apr 11 2016 08:37:06 GMT+0530 (IST)

Help me please!!!

I do not find moment-timezone converting UTC dates to proper timezone-dates. There always seem to be a 1 hr difference. :'( :'(

Moment.js member

@qbAnu - Please do not comment on old issues to ask for help. As you can see, your question was easily overlooked.

For the specific issue you mention, it's because you're supplying an import format that doesn't match the input. You probably meant that to be an output format, as in:"2016-04-11T03:07:06.000+0000", "Europe/Berlin").format("MMM DD YYYY hh:mm:ssA")
// "Apr 11 2016 05:07:06AM"

I'm not sure what you mean on the last sentence. But please, if you need help then either open a new issue or ask on Gitter. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment