9

This is as low as I can seem to go with javascript date:

var myDate = new Date(0, 0, 1);
myDate.setFullYear("-271800");
alert(myDate);

Anything lower than -271,800 BC throws an invalid date error. Can we go back a million years? Or a billion? Can the date object allow you to describe any date infinitely in the past or future? How might I do something like this?

Jay Riggs
  • 53,046
  • 9
  • 139
  • 151
Devin McQueeney
  • 1,277
  • 2
  • 14
  • 31

4 Answers4

10

Representing a particular date a million years ago strikes me as meaningless. Julian calendar? Should days of week honor the Babylonian system?

Create your own type for this, decide what you actually need to represent.

--- Updated: This was accepted, so I'll add a few more specific bits. ---

As mentioned in another answer, according to the EcmaScript spec, pg 164 of the fifth edition (link is a .pdf.)

Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day. ECMAScript Number values can represent all integers from –9,007,199,254,740,991 to 9,007,199,254,740,991; this range suffices to measure times to millisecond precision for any instant that is within approximately 285,616 years, either forward or backward, from 01 January, 1970 UTC.

The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC.

But, this is for theoretical dates. It ignores a few pieces of reality. Days were shorter (by 12 seconds) a million years ago, so some JavaScript math would be inaccurate. Days of the week have been determined with different systems. Months have been defined differently. All to say, decide what you really need to represent.

Jamie F
  • 23,189
  • 5
  • 61
  • 77
  • Yeah - thinking about how to build a universal date / time selector is quite complex when you think about it. The further back in time, the shorter the days get too. It may just be necessary to reduce accuracy down to a year over some threshold. Time is also relative to location. Days are quite a bit longer on Pluto. – Devin McQueeney Jan 14 '12 at 22:10
3

The ECMAScript standard requires the Date object to be able to represent any date and time, to millisecond precision, within 100 million days before or after 1/1/1970. This is a range of plus or minus 273,785 years. In order to represent dates outside of this range you would need to implement your own date object that did not operate on millisecond resolution.

Dylan Bijnagte
  • 1,326
  • 9
  • 17
3

You should build your own DateTime for that. It's complexity depends on what you want to achieve...if you want to represent only year, then it is just a simple number...if you want to say what date was the last Sunday in 1 200 000 BC, it is more complex...but have on mind that Sundays didn't exist in that year :)...Gregorian calendar that we use now is introduced 1582 AD, Julian calendar 45 BC (and I'm not sure what was before that). I don't think that even javascript DateTime takes into account that, so setting it to year 271800 BC doesn't make sense.

Aleksandar Vucetic
  • 14,715
  • 9
  • 53
  • 56
1

According to https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date:

The JavaScript date is measured in milliseconds since midnight 01 January, 1970 UTC. A day holds 86,400,000 milliseconds. The JavaScript Date object range is -100,000,000 days to 100,000,000 days relative to 01 January, 1970 UTC.

The JavaScript Date object provides uniform behavior across platforms.

Resources are finite and a developer has to make a compromise between storage, performance and range for any given datatype. IMHO the ecmascript range for dates is large enough for any practical matter.

Paulo Scardine
  • 73,447
  • 11
  • 124
  • 153
  • There are lots of valid and practical reasons to go back more than 250k years and want the simplicity of a "native well tested/documented" object. The OP question said asked if Date can't do it, what can. – Aaron Sherman Mar 12 '15 at 18:09
  • @AaronSherman: Do you care to name some of those practical reasons? Honest question, with my obtuse intellect I can't imagine why our current calendar would matter for an event occurred in middle of the paleolithic. – Paulo Scardine Mar 12 '15 at 21:59
  • timeline web apps are what come to mind to me. I realize there are lots of other solutions than a pure datetime, but having the ability to easily scale from paleolithic to modern times is actually quite nice. Example timelines with this issue: http://scholarslab.org/research-and-development/parsing-bc-dates-with-javascript/ and https://github.com/NUKnightLab/TimelineJS/issues/273 – Aaron Sherman Mar 12 '15 at 22:23
  • All due respect it is quite a stretch to say that microsecond resolution is practical for such scale. – Paulo Scardine Mar 12 '15 at 22:52
  • I agree microsend resolution of more than 500k year is overkill, and that the spec is very reasonable. My comment is it not unreasonable to ask if a well tested object that can go back more than 250k years and have the concept of time exists. It is also reasonable to say "This object doesn't exist, but could be built." – Aaron Sherman Mar 13 '15 at 12:56