2

(EDIT: I am using chrome console for the code below)

I realize that javascript Date() is deprecated, but it's useful for something I'm currently working on; however there is a strange problem:

var x = new Date('999').getFullYear()

returns 999

while 

var x = new Date('1000').getFullYear()

returns 999 as well, but

var x = new Date('10000').getFullYear()

returns 10000...

Does anyone know why do 4 digit numbers give the wrong .getFullYear()?

OneThreeSeven
  • 422
  • 5
  • 13
  • 4
    Since when is `Date` "deprecated"? By whom? – Pointy Sep 14 '12 at 21:26
  • Oops! I thought I read that while I researching this. See http://stackoverflow.com/questions/460423/why-was-new-dateint-year-int-month-int-day-deprecated, I guess I misunderstood it... – OneThreeSeven Sep 14 '12 at 21:31
  • Date parses the string as a UTC date, but since you are in specific time zone, `new Date('1000')` is maybe on the 31th of December in your time zone? – Manuel Leuenberger Sep 14 '12 at 21:33

5 Answers5

2

Take a look at this page. You are passing a string which is passed to this parse method. The first argument isn't "years" unless you pass 3 integers. Finally while the class itself isn't being deprecated, some of it's members are (including getYear() which is being replaced with getFullYear() which you are using`)

Jason Sperske
  • 29,816
  • 8
  • 73
  • 124
2

As the other answers suggest, you can't rely on Date.parse across browsers, especially if you are dealing with dates before 1000 CE.

As far as Chrome is concerned, it looks like the issue is how the browser deals with timezones. The following example suggests that before 1000 CE, Chrome parses the date in your local timezone on top of it; >= 1000 CE, it appears to first parse the date in UTC, then applies the timezone conversion:

> new Date('1000')
"Tue Dec 31 999 16:00:00 GMT-0800 (PST)"
> new Date('999')
"Tue Jan 01 999 00:00:00 GMT-0800 (PST)"

I'd be inclined to see this as a bug, but perhaps the Chromium team thinks it's a feature :).

The bottom line is that, if you want accurate date parsing for years, especially ancient years, you need to do some work yourself and/or use a library. Moment.js and Datejs both might help, but I doubt either deals well with ancient years. Moment.js seems to have the same issue (in Chrome):

> moment('999').year()
999
> moment('1000').year()
999

The best way I know of to accurately set dates based on ancient years is generally to a) always use UTC, and b) set the date manually:

var d = new Date();
d.setUTCFullYear('999');
d.getUTCFullYear(); // 999
d.setUTCFullYear('1000');
d.getUTCFullYear(); // 1000

In Chrome at least, this works with both strings and integers.

You might also be interested in the gregorian parser in the Timemap.js library, which handles ancient years with AD, CE, BC, and BCE extensions, as well as negative numbers.

nrabinowitz
  • 55,314
  • 10
  • 149
  • 165
1

This fiddle says otherwise on Firefox. Perhaps it's browser related?

zmbq
  • 38,013
  • 14
  • 101
  • 171
0

alert(new Date('999').getFullYear()); yields NaN on Firefox 15.0.1

Hmm.. Chrome 21.0.1180.57 does yield '999'

Jeremy J Starcher
  • 23,369
  • 6
  • 54
  • 74
0
var x = new Date('10000').getFullYear()

change it to 

var x = new Date(10000).getFullYear()

you are sending an invalid datestring to the date constructor.

user1655481
  • 376
  • 1
  • 10