570179 - Error in getDate() when Object Date is created whith - ej: 2010-06-04

Status: RESOLVED DUPLICATE of bug 1275502

(Core :: JavaScript Engine, defect)

Description

[Xava]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100402 Namoroka/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100402 Namoroka/3.6.3

The best way to details this is with a example:

javascript: var d = new Date('2010-06-04'); alert(d.getDate());

d.getDate is the value: 3  (will be the value: 4)



other example

javascript: var d = new Date('2010-06-01'); alert(d.getDate());

d.getDate is the value: 31  (will be the value: 1)

Reproducible: Always

Steps to Reproduce:
1.execute the javascript code drescribed in "Details"
2.
3.
Actual Results:  
the result is a day minnor 

Expected Results:  
the correct day!!

nothing :)

Comment 1

[Boris Zbarsky [:bzbarsky]]

The issue seems to be what timezone '2010-06-04' is assumed to be in.  We seem to assume that '2010-06-04' is equivalent to '2010-06-04T00:00:00Z' (so in the UTC timezone), but getDate returns the date in your _local_ timezone; if you're west of Greenwich, that will end up as '3'.

ECMA-262 doesn't seem to actually say what timezone should be assumed for '2010-06-04', though it also seems to imply that it doesn't fall under th e"just guess" clause of malformed dates....

waldo, am I missing something, or is this in fact underspecified?

Comment 2

[joshua.hoke]

I also ran into this, and found that, e.g., Date.parse('2010/06/04') assumes the local time zone instead of GMT. (That is, Date.parse('2010/06/04') and Date.parse('2010-06-04') give two different answers.) I will attach a quick demo page that shows this.

I am using Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10) Gecko/20100920 Fedora/3.6.10-1.fc13 Firefox/3.6.10

Comment 3

[joshua.hoke]

Attachment: Test case for date parsing

Comment 4

[joshua.hoke]

Attachment: Test case for date parsing

I found that "2010-06-04T00:00" produces the same parse result as "2010/06/04" but a different one from "2010-06-04". Is there a good reason for the code to assume different time zones based on how much of an ISO 8601 date is specified?

I've added this third case to the test page.