I have this simple Javascript code
var d = new Date(2011, 9, 8);
alert(d); // Show: Fri Oct 7 23:00:00 UTC-0400 2011
Important: My Time Zone is "Santiago de Chile", and I set computer clock to: 2-Oct-2011.
Alert show that Day is 7!!... why? How I can get it right? (Problem is only in this day)
According to this page DST change in Chile is always at the second full weekend of October and starts at midnight (lets disregard the extended DST of this year, as it's very likely your computer doesn't know about it).
That means that, as is also shown using the script I linked to earlier, at your timezone 8 Oct 2011 midnight can't be represented in UTC-0300, so it automatically switches to UTC-0400 to represent the same time.
I can reproduce your issue in my timezone (Amsterdam, UTC+1/2h) by asking for Sun 27 March 2011, 2:00 AM (with current timezone CEST=UTC+0200) (at which time summer time (CEST) starts and the clock is adjusted from UTC+0100 to UTC+0200) (remember this is exactly the opposite on the northern hemisphere))
new Date(2011, 2, 27, 2, 0, 0, 0);
which effectively can't be represented in UTC+0200, so the system chooses UTC+0100 and outputs
Sun Mar 27 2011 01:00:00 GMT+0100 (CET)
So, it's the same time in Unix time, only represented differently in your local timezone.
And yes, I know 8 October is a Saturday and DST change starts at Sunday, midnight, but this is the closest I can get.
Update: I can now reproduce your issue by setting the timezone of a WinXP machine to Santiago and let the OS automatically adjust for DST and alerting new Date(2011, 9, 9) (which is a Sunday and is shown as a Saturday; there must be something strange with your settings). Of course you can't control these settings on the client.
To work around this issue, I have to know what you exactly need: if you merely want some date/time display that doesn't take timezone and DST into account, just use UTC, like:
var d = new Date(Date.UTC(2011, 9, 9));
alert(d.toUTCString()); // Shows: Sun, 9 Oct 2011 00:00:00 UTC
To show/calculate with the individual parts of the Date object, use the corresponding UTC methods.
Related
Why is it when I have
var dt = new Date(2015, 6, 1);
dt.toUTCString()
My output is Tue, 30 Jun 2015 23:00:00 GMT
And
var dt = new Date(2015, 6, 2);
dt.toUTCString()
Wed, 01 Jul 2015 23:00:00 GMT
I'm clearly missing something here, I want to be able to loop through each days of the month and get a Date() for that day
I don't understand why if the day is 1, it says the date is the 30th
Javascript dates are always generated with local time zone. Using toUTCString converts the time in the Date object to UTC time, and apparently in your case that means -1 hours. If you want to initialize a Date object with UTC time, use:
var dt = new Date(Date.UTC(2015, 6, 1));
The toUTCString() method converts a Date object to a string, according to universal time.
The Universal Coordinated Time (UTC) is the time set by the World Time Standard.
Note: UTC time is the same as GMT time.
Try to change dt.toUTCString() in another function.
There are a lot of hour on the planet,for example in America is the 5 o' Clock,in Japan is 10 o' Clock etc... the UTC is a time zone,try to change this.
I have a client side web application where the user must create Dates for timezones other then their own, and I'm not sure of the best way to do this.
Using Moment Timezone, I know how I can change a time into another timezone. That is, convert Nov 18 2013 11:00:00 GMT-0500 to Nov 19 2013 03:00:00 GMT+1100. These still represent the same absolute time, but just with a different 'view'.
What I need to do is convert, respecting daylight savings, Nov 18 2013 11:00:00 America/Toronto" to Nov 18 2013 11:00:00 Australia/Sydney (which are different absolute times).
So far the only way I can come up with is to create a Date, serialize it to string, and then parse it with Moment Timezone, something like:
localEvent = new Date(2015, 03, 10, 18, 30)
eventStr = localEvent.toString().split('GMT')[0]
# eventStr = 'Fri Apr 10 2015 18:30:00'
event = moment.tz(eventStr, 'Australia/Sydney')
So now this code will create the exact same point in time regardless of which timezone the browser is operating in.
But this feels very hacky, is there a better way to do this?
Yes, you can do that better:
var zone = moment().tz('Australia/Sydney');
var c = moment(new Date(2015, 03, 10, 18, 30));
c.utcOffset(zone.utcOffset(), true);
// ^--- this flag keeps the same time
// while shifts a timezone
console.log(c.format());
JSFiddle: http://jsfiddle.net/8m6rdzqj/
How I found it: I just went through the moment and moment-timezone source: https://github.com/moment/moment-timezone/blob/master/moment-timezone.js#L347
I have created a date variable pointing to 9th of July 2014
var date = new Date(2014, 6, 9);
When I try to obtain the time from this date, I expect that the time variable
var time = date.getTime();
would give me the value milliseconds value of July 9th 2014 at 00:00:00.
Instead it gives me
1404860400000
which is the milliseconds value of 8th July 2014 at 23:00:00.
Can someone explain me why this?
Your code here:
var date = new Date(2014, 6, 9);
creates a Date instance initialized to your local time of midnight on July 9th, 2014. Timestamp numbers (both JavaScript's milliseconds-since-the-Epoch and Unix's seconds-since-the-epoch) are unaffected by timezones, the value is since midnight Jan 1 1970 UTC.
If you were to construct this date:
var newDate = new Date(1404860400000);
...you'd have a date that was exactly equivalent to your first one. If you asked it for the local version of the moment it represented, it would say midnight on July 9th, 2014.
In both date and newDate above, if you ask it the UTC version of the date, you'll see it's offset from midnight (the direction depends on where you are, west or east of Greenwich, England). At the moment I'm writing this, almost no one is on GMT, not even those of us in the UK who normally are, because of Summer time. But for most people who are never in GMT, the value will always be offset.
If you want a Date instance giving you midnight on July 9th, 2014 UTC (e.g., not local time), use new Date(Date.UTC(2014, 6, 9)). Date.UTC gives you the time value for the given date in UTC, and then if you feed that time value into new Date, you get a Date for it.
January 1, 1970 :
getTime() Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object. Returns: the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this date.
Google.
The Mozilla docs usually cover documentation issues like this quite well.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
I am facing very strange issue kindly take a look at two examples below.
My Development Environment Time Zone: GMT+0500
When i use following function:
var d = new Date("Tue Mar 18 2014 00:00:00 GMT+0500");
var n = d.getUTCDate();
n = 17 which is correct (Return the UTC day of the month of a specific, local time, date-time) and everything works perfectly in my timezone.
My Clients Time Zone: GMT+0000
var d = new Date("Tue Mar 18 2014 00:00:00 GMT+0000");
var n = d.getUTCDate();
n = 18 which is wrong
any one put some light why is that? how to resolve this issue?
any help would be appreciated.
n = 18 which is wrong
No it's not. You supplied GMT+0000, which is the same as GMT or UTC. So the result from getUTCDate is of course the date you passed in.
I think you are confused because of how you worded this:
My Development Environment Time Zone: GMT+0500
My Clients Time Zone: GMT+0000
A time zone is not a numeric offset. A time zone can have an offset, or multiple offset, and includes the history of how the offsets have changed over time. See "Time Zone != Offset" in the timezone tag wiki.
So those might be the current offsets for you and your client, but that doesn't necessarily mean that they are always going to be in the same offset. If your client is in the UK, then they are at +0000 now, but they will soon be on +0100. See here for details.
Your first date is explicitly constructed with a time zone that results in the UTC date being 17. At midnight of the 18th in the timezone 5 hours ahead of UTC (GMT), it's still the 17th in London. Your second date is constructed with the explicit UTC timezone. At the time indicated by your second date, in other words, it's 5 o'clock in the morning in the first timezone.
In Moment.js I have the next problem:
1.I create a moment date:
var m = moment(new Date(2014, 9, 18, 0, 0, 0));
2.If I call toString function:
m.toString() //"Sat Oct 18 2014 00:00:00 GMT-0300"
3.Now, I add one day I have the next output:
m.add("days",1).toString() //"Sat Oct 18 2014 00:00:00 GMT-0300"
What I get 18 again? Momentjs should change the date.
EDIT: Issue in Chrome 32.0.1700.76 m
EDIT2: MomentJs version 2.5.1
EDIT3: Timezone UTC-3
I have looked at you code and at first I did not get the same results. However when I changed the timezone to Brazil (GMT-03:00) - Sao Paulo I got the same result. This is clearly a bug and has now been traced to V8 and reported.
Plunker
var m = moment(new Date(2014, 9, 18, 0, 0, 0));
console.log(m.toString());
console.log(m.add("days",1).toString());
Sat Oct 18 2014 00:00:00 GMT-0300 script.js:4
Sat Oct 18 2014 00:00:00 GMT-0300 script.js:5
I have submitted a bug: https://github.com/moment/moment/issues/1440
Update
Moment.js is not responsible for this bug. It has been tracked to a bug in V8 (the javascript engine used by both Chrome and Node). I have filed a bug with V8 that you can follow here: https://code.google.com/p/v8/issues/detail?id=3116
Here is the work that Isaac Cambron did to track it down.
OK, reproduced now in both Ubuntu and OSX (I was using a different Brazilian city in my tests before). I'm using Node, not Chrome, but for our purposes V8 is V8.
moment([2014, 9, 18]).add(1, 'd').format(); //=> '2014-10-18T00:00:00-03:00'
The problem is that Moment essentially does this:
var d = new Date(2014, 9, 18);
d.setDate(19);
d.toString(); // => Sat Oct 18 2014 23:00:00 GMT-0300 (BRT)
//wtf?
Then it sets the hours to zero. Since V8 weirdly sets the time to late on Oct 18 even though we specifically asked it to set it to Oct 19, the answer comes out wrong. This is all especially weird because the DST transition here is a jump forward, meaning if anything it should end up 1:00, not 23:00 the previous day.
In fact, it even does this:
new Date("October 18, 2014"); //=> Sat Oct 18 2014 00:00:00 GMT-0300 (BRT)
new Date("October 19, 2014"); //=> Sat Oct 18 2014 23:00:00 GMT-0300 (BRT)
According to this jsFiddle, what you're doing /should/ be working. What browser are you testing in?
http://jsfiddle.net/mori57/Nq3KD/
var m = moment(new Date(2014, 9, 18, 0, 0, 0));
console.log(m.toString()); // Firebug output: Sat Oct 18 2014 00:00:00 GMT-0400
console.log(m.add("days",1).toString()); // output: Sun Oct 19 2014 00:00:00 GMT-0400
Simply you can use the below code to get next date in moment.js
var date='2014/09/18';
var nextDate = moment(date, 'YYYY/MM/DD').add('days', 1).format('YYYY/MM/DD');
console.log(nextDate); // 2014/09/19
For more details , look at below link
momentjs docs
This is a rather old post but I got here via Google with the same issue. What I ended up using was the following code, maybe this is helpful for someone else:
var then = moment("23.07.2014", "DD.MM.YY");
var before = moment.unix(then.unix()-86400); // 86400 seconds/day
var after = moment.unix(then.unix()+86400);
General remark to avoid issues like this (as you can see, they do happen, and are sometimes happening due to a browser bug): if you represent a day using Date object, you can just have a convention to pass noon (12h00) instead of midnight (00h00) to the Date constructor, and then in the function that prepares date for display, cut it off.
The bugs in browsers, and issues due to DST usually shift the time by one hour (time goes back from 00h00 to 23h00 the previous day). If you just use midday, it should not happen (in case of similar bugs, time will go back from 12h00 to 11h00 for instance, but the day will not change).
(Of course you need to remember that the date is noon when you pass it around, sometimes it might not be good)
For instance, have a look at this bug in YUI library which we were using in on of our company apps:
https://github.com/yui/yui2/pull/15
This happened only in Firefox, only on Windows, only in particular timezone, and only in particular month. But it did happen.
You should pass the number first and then the "days"
var m = moment(new Date(2014, 9, 18, 0, 0, 0));
console.log(m.toString());
console.log(m.add(1, "days").toString());
Tested in Chrome Version 50.0.2661.37 beta-m (64-bit)