User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36 Steps to reproduce: new Date(2013,3,1) Actual results: This produces 2013-03-31 only when the Web Console is open. Expected results: Should produce 2013-04-01. The issue affects the running code and not just the console.

Paul, can you expand on your steps to reproduce a bit? Specifically, how did you check the value of the Date object produced by website code? Did you by any chance do `console.log(new Date(2013,3,1))`? In the console, dates are stringified using a pretty printer. The result of that is a date string in the GMT timezone. If your timezone is ahead of GMT (as mine is), that will print the day before, perhaps explaining what you're seeing.

--> needinfo flag set Also, what is your timezone?

My timezone is GMT. If I use new Date(2013,3,1) in code or in the console, the returned date is the 31st March and not 1 April. This only happens when using the web console. If I use firebug or another browser, it is correct. Seems to just be a firefox (built-in) console issue that affects the javascript too when it is open.

(In reply to Paul Clark from comment #3) > My timezone is GMT. Interesting, ok. > If I use new Date(2013,3,1) in code or in the console, the returned date is > the 31st March and not 1 April. > This only happens when using the web console. If I use firebug or another > browser, it is correct. Seems to just be a firefox (built-in) console issue > that affects the javascript too when it is open. Can you please give exact steps to reproduce? By that description, it could still be a display issue or an issue with the actual date being stored.

Open the web console (not firebug), type in new Date(2013,3,1) The returned value is incorrect. The bug in the web console also affects the javascript code in the page. Performing many minor tasks pertaining to date becomes very difficult, especially when debugging. Try a jsfiddle to try it out.

I'm truly sorry, but those are still not really actionable steps to reproduce. I know it's a pain, but without being able to exactly understand what you're seeing and what you expect to see, it's difficult to help. Can you give me a set of steps roughly like the following? 1. visit [url to specific jsfiddle entry] 2. open the web console 3. run fiddle Expected result: The following string should have been logged in the web console: [exact string you expect] Actual result: The following string is logged in the web console. An additional important question: are you saying that opening the web console actually changes the outcome of operations using that date within the web page itself? Not as printed in the web console, but as used in the web page and, e.g., printed into a text input field?

Yes, it is changing the result in the web page too, but only if the web console is open. If firebug is open instead, then the result is correct. The web console must be prototyping the date.

Ok, that sounds bad. I still cannot do much about it without being able to fully understand what you're seeing. For that, the steps to reproduce as requested in comment 6 are essential.

I suspect this is what is really going on: 0) be in British summer time (which unlike comment #3, is really GMT+1, even if people in this country reflexively say they are in GMT) 1) open the web console on any page (like this one) 2) evaluate: new Date(2013,3,1) >> returns Date 2013-03-31T23:00:00.000Z (NB: this is midnight on the first of April, GMT+1, so that seems correct to me) 3) open firebug's console on the same page 4) evaluate: new Date(2013,3,1) >> returns Date {Mon Apr 01 2013 00:00:00 GMT+0100 (BST)} (NB: this is *exactly the same moment in time*, just formatted differently (with a different timezone) for display!) optional: store either of the two dates in a local variable, and evaluate the same local variable in the other console, and you'll see they are equivalent. I don't think this is a bug - if anything, one might argue that the web console should use local timezones for displaying dates. I don't feel strongly either way, but would personally prefer actual UTC/GMT/zulu as it does now. Paul, can you let us know whether my analysis is correct?

That does sound correct, but the issue is that if the resulting date object would pass a different date and month, compared to any other situation, then it will let site code make mistakes if this console is open.

Paul, I'm pretty sure by now that this is purely an issue with how dates are displayed in the browser console. As far as I can tell from what you wrote so far, the site *doesn't* change its behavior if the console is open: it's just that *all* dates in the console show this behavior. If you still think that this really is changing the site's behavior, we'll need some more tangible proof for that. One way to get that would be to give us steps to reproduce as I requested in comment 6. An easier one would be to just do `console.log(myDate.getMonth())`. I'm pretty sure that's going to print "3", not "2", verifying that the date is still correct.

Both here and in bug 1079720, printing dates in UTC seems to cause confusion, so it might be better to always use the local timezone instead.

what's the state of this bug? just waiting for a patch, or is there anything to discuss what format to use?

(In reply to Tooru Fujisawa [:arai] from comment #16) > what's the state of this bug? > just waiting for a patch, or is there anything to discuss what format to use? I do not know. Perhaps Nicholas does. Or maybe :bgrins but he's unavailable for the time being. Right now I think this might require a two-part fix, one part in the old console and one part in the devtools-reps project: https://github.com/devtools-html/reps

The bug isn't worked on at the moment. > Right now I think this might require a two-part fix, one part in the old console and one part in the devtools-reps project: https://github.com/devtools-html/reps I don't know if there's any value on working on the old console since we are (hopefully) planning to launch the new one in the next months. But it is true that there is other places in the devtools where we use the iso string when displaying dates : in the Date reps (which is then used in the console, the debugger, the Dom panel, ...) and in the Variable view. The variable view might be killed in the future in favor of an object inspector (a-la chrome), so we might save a bit of work here. Speaking of the bug itself, it looks legitimate to me, and it'd be better for the user to have the date shown in their timezone to avoid confusion. I filed https://github.com/devtools-html/reps/issues/114 in the reps repo for that purpose, thanks for raising that up arai !

now the issue is tracked in https://github.com/devtools-html/devtools-core/issues/400

moved to https://github.com/devtools-html/debugger.html/issues/6153