construct moment in zone

[moment]

construct moment in zone

[pelme]

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:
http://bazaar.launchpad.net/~stub/pytz/devel/view/head:/src/pytz/tzinfo.py#L244

Here are some tests for localize() which would probably be very useful when implementing this:
http://bazaar.launchpad.net/~stub/pytz/devel/view/head:/src/pytz/tests/test_tzinfo.py#L588

What would the best API be? I think that something like this would make sense look the same as moment.utc()

moment.tz('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')

[neverfox]

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.

[timrwood]

There is a naive wrapper method already.

moment-timezone/moment-timezone.js

Lines 473 to 479 in 2a13473

	moment.tz = function () {
	var args = [], i, len = arguments.length - 1;
	for (i = 0; i < len; i++) {
	args[i] = arguments[i];
	}
	return moment.apply(null, args).tz(arguments[len]);
	};

moment.tz(input, zoneName);
moment.tz(input, format, zoneName);
moment.tz(input, 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!

[hurrymaplelad]

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

[hurrymaplelad]

Another test case:

moment.tz([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.

[marcphilipp]

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 = moment.tz(timezone);
  result.year(sourceMoment.year());
  result.month(sourceMoment.month());
  result.date(sourceMoment.date());
  result.hour(sourceMoment.hour());
  result.minute(sourceMoment.minute());
  result.second(sourceMoment.second());
  result.millisecond(sourceMoment.millisecond());
  return result;
}

[alanhamlett]

I currently parse dates in various timezones like this:

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

A shortcut moment method would be nice.

[mattjohnsonpint]

@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.

[neverfox]

Yeah, to correct method is most likely going to require referencing the
moment-timezone data rule that applies to the supplied date (string or
array) and running it in "reverse" to obtain a moment (which would display
as UTC, local, or another timezone as directed).

On Fri, Sep 13, 2013 at 10:18 AM, Matt Johnson - [email protected] <
github.soma.3d1062736b.notifications#[email protected]> wrote:

@alanhamlett https://github.com/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 https://github.com/marcphilipp - your implementation makes
a similar mistake.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-24410107
.

[neverfox]

Ah so this was handled in #25?

[alanhamlett]

@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:
https://bitbucket.org/pellepim/jstimezonedetect

[alanhamlett]

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

[mattjohnsonpint]

@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.

[briancray]

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

[r-barnes]

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:

moment.tz('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.

[vgrigory]

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

meaning, e.g.:
moment.tz("2013-11-18 11:55", "America/Toronto").unix() and moment.tz("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)

[neverfox]

@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.

[vgrigory]

yep, in moment.tz v0.05 this is fixed

[timrwood]

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

[froodian]

This still appears to be an issue in some cases - on the momentjs.com website, I get the following results:

moment.tz("2002-9-28 11:55", "Europe/Berlin").unix()
1033228500
moment.tz("2002-9-28 11:55", "America/Los_Angeles").unix()
1033228500

[timrwood]

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

See the 'Supported ISO 8601 strings' section at http://momentjs.com/docs/#/parsing/, all those rules apply to moment.tz(String, 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.

moment.tz("2002-09-28 11:55", "Europe/Berlin").unix()       // 1033206900
moment.tz("2002-09-28 11:55", "America/Los_Angeles").unix() // 1033239300

[froodian]

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

[yocontra]

How about supporting parsers?

moment.tz('Tuesday 9:00PM', 'dddd hh:mm', 'America/Los_Angeles')

I don't think this works currently

[mattjohnsonpint]

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

var b = moment.tz("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'

[alanhamlett]

This looks like a bug:

moment.tz('03/06/2015', 'America/Los_Angeles').format();
"2015-03-05T16:00:00-08:00"

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

It only works correctly in the last case:

moment.tz('2015/03/06', 'America/Los_Angeles').format();
"2015-03-05T16:00:00-08:00"
moment.tz('03-06-2015', 'America/Los_Angeles').format();
"2015-03-05T16:00:00-08:00"
moment.tz('2015-03-06', 'America/Los_Angeles').format();
"2015-03-06T00:00:00-08:00"

[alanhamlett]

Nevermind, specifying a format string fixes it:

moment.tz('03/06/2015', 'MM/DD/YYYY', 'America/Los_Angeles').format();
"2015-03-06T00:00:00-08:00"

[anusreemn]

Hi,

To convert a UTC date string to a specified timezone in a formatted manner, I tried the below:
moment.tz("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. :'( :'(

[mattjohnsonpint]

@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:

moment.tz("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.