Javascript date 01/01/0001
Asked Answered
S

7

49

I want to create a Date object in javascript, which represents the year 0001, 2014 years ago.

I tried with

d = new Date();
d.setYear(1);
console.log(d);

but it gives the year 1901

with

d = new Date(1,1,1)
console.log(d);

no way.

How can I create this date?

Sloane answered 30/4, 2015 at 12:44 Comment(0)
D
54

First of all it's not a Y2K issue at all! ( UPDATE: in some cases - it's related to Y2K issues, but it's not the problem here )

The correct answer is that you can't do that reliably. Does Daylight saving time apply to year 1? How many Leap Years were there? Were there any? Etc. But the answer by @Daniel will use it!

UPDATE: not to mention @MattJohnson post about DST. DST in year 1, actually JS (ES5 anyway) will lie and use the current DST rule for all years

So please don't fool yourself with the idea that you can reliably work with dates lower than 1970. (You will have a lot of problems and surprises even in that time range.)

But if you really, really need to you can use new Date('0001-01-01') (ISO 8601 format) or @Daniel's method:

var d = new Date(); d.setFullYear(1);

But before you use it read this...


There are 4 ways to create a Date in JS:

new Date()
new Date(milliseconds)
new Date(dateString)
new Date(year, month, day, hours, minutes, seconds, milliseconds)

1) new Date() creates current date ( in your local timezone ) so we are not interested in it for now.


2) new Date(number) creates a new date object as zero time plus the number. Zero time is 01 January 1970 00:00:00 UTC.

So in this case time in JS counting from year 1970.

(new Date(0)).toUTCString()
"Thu, 01 Jan 1970 00:00:00 GMT

If you use negative number you can go "back" it time before 1970

(new Date(-62167219200000)).toUTCString()
"Sat, 01 Jan 0 00:00:00 GMT"
-62167219200000             <- milliseconds
-62167219200000 / 1000
-62167219200             <- seconds
-62167219200 / 60
-1036120320             <- minutes
-1036120320 / 60
-17268672             <- hours
-17268672 / 24
-719528             <- days
-719528 / 365
-1971.309589041096 <- years ( this is roughly calculated value )

The problem is that it's not reliable. How many Leap Years were there? Were there any? Daylight saving time? Etc. And I don't like it because of this magic number -62167219200000


3) new Date(dateString) This is most 'reliable' way. DateString - A string representing an RFC2822 or ISO 8601 date.

RFC2822 / IETF date syntax (RFC2822 Section 3.3), e.g. "Mon, 25 Dec 1995 13:30:00 GMT"

The problem with it is that if you use negative number you will get an incorrect Date with NaN in a result of all methods

(new Date('01 January -1 00:00:00 UTC')).getFullYear()
NaN

If you use year higher or equal 0 and lower then 50 then 2000 will be added automatically.

(new Date('01 January 0 00:00:00 UTC')).getFullYear()
2000
(new Date('01 January 1 00:00:00 UTC')).getFullYear()
2001
(new Date('01 January 10 00:00:00 UTC')).getFullYear()
2010
(new Date('01 January 01 00:00:00 UTC')).getFullYear()
2001
(new Date('01 January 30 00:00:00 UTC')).getFullYear()
2030
(new Date('01 January 49 00:00:00 UTC')).getFullYear()
2049

And if you use year higher or equal 50 and lower then 100 then 1900 will be added.

(new Date('01 January 50 00:00:00 UTC')).getFullYear()
1950
(new Date('01 January 51 00:00:00 UTC')).getFullYear()
1951
(new Date('01 January 90 00:00:00 UTC')).getFullYear()
1990
(new Date('01 January 99 00:00:00 UTC')).getFullYear()
1999

Years equal 100 or higher will get correct year number

(new Date('01 January 100 00:00:00 UTC')).getFullYear()
100
(new Date('01 January 101 00:00:00 UTC')).getFullYear()
101
(new Date('01 January 999 00:00:00 UTC')).getFullYear()
999
(new Date('01 January 9999 00:00:00 UTC')).getFullYear()
9999

So we can't create year 1 using RFC2822 / IETF date syntax

About ISO 8601:

http://www.w3.org/TR/NOTE-datetime

The actual formats are

Year:
      YYYY (eg 1997)
Year and month:
      YYYY-MM (eg 1997-07)
Complete date:
      YYYY-MM-DD (eg 1997-07-16)
Complete date plus hours and minutes:
      YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
Complete date plus hours, minutes, seconds and a decimal fraction of a second
      YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)

We are most interested in 'Complete date'

(new Date('0001-01-01')).toUTCString()
"Mon, 01 Jan 1 00:00:00 GMT"

Yahoo!!! ( or it is better to say Google! :) ), we can use ISO 8601 to create date with year 1

But be careful and do not try to use negative numbers or short year numbers, as parsing of those will may vary on localization or just insanity :)

(new Date('-0001-01-01')).toUTCString()
"Sun, 31 Dec 2000 21:00:00 GMT"
(new Date('01-01-01')).toUTCString()
"Sun, 31 Dec 2000 21:00:00 GMT"
(new Date('02-01-01')).toUTCString()
"Wed, 31 Jan 2001 21:00:00 GMT"
(new Date('02-01-05')).toUTCString()
"Mon, 31 Jan 2005 21:00:00 GMT"

4) new Date(year, month, day, hours, minutes, seconds, milliseconds)

To use this one you have to pass two parameters ( year, and month ), all other will be optional. Be careful because here month will start from 0 to 11, not like everywhere else. WAT? o_O

WARNING! This date will be created in your current time zone!!! So be careful using it!

UPD: clarification by @matt-johnson

...actually the Date object always reflects the local time zone. You can't place it in another time zone, and even if you initialize it with a UTC timestamp, it will still reflect back the local time zone in most of the functions. Internally it tracks UTC by the numeric timestamp, and there are functions that expose UTC values explicitly, but everything else is local.

The negative numbers will be interpreted as negative years

(new Date(-1, 0)).toString()
"Fri Jan 01 -1 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(-234, 0)).toString()
"Wed Jan 01 -234 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"

The numbers from 0 to 99 will be incremented by 1900 automatically

(new Date(0, 0)).toString()
"Mon Jan 01 1900 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(1, 0)).toString()
"Tue Jan 01 1901 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(11, 0)).toString()
"Sun Jan 01 1911 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(50, 0)).toString()
"Sun Jan 01 1950 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(99, 0)).toString()
"Fri Jan 01 1999 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"

The numbers from 100 to 275760 will be interpreted as year numbers

(new Date(100, 0)).toString()
"Fri Jan 01 100 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(102, 0)).toString()
"Sun Jan 01 102 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(2002, 0)).toString()
"Tue Jan 01 2002 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"

And numbers higher then 275760 will be Invalid date

(new Date(275760, 0)).toString()
"Tue Jan 01 275760 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)"
(new Date(275761, 0)).toString()
"Invalid Date"

UPD:

new Date(Date.UTC(1,1,1)) will safer from same symptoms as new Date(year, month, day, hours, minutes, seconds, milliseconds). Because of Date.UTC function.

Drawl answered 30/4, 2015 at 14:12 Comment(12)
When I am trying to get UTC dates, I tend to use new Date(Date.UTC(1,1,1)) as opposed to string parsing. Mind you, I've never tried it with that early of a date before.Komsomolsk
new Date(Date.UTC(1,1,1)) will safer from same symptoms as new Date(year, month, day, hours, minutes, seconds, milliseconds). Becouse of Date.UTC function...Drawl
It is related to y2k because the setYear and constructor functions were both originally designed to accept a two-digit (or one-digit for 0-9) year and still do so with years in the range 0-99 for backwards compatibility.Alloway
In some way - yes, but only when you work with new Date(dateString) and new Date(year, month... ) if you use new Date(number) - there is other issue.. so saying 'this is the Y2K issue with JavaScript.' is not true. But anyway this is only my opinion :)Drawl
Nice response. Comprehensive and accurate. One point of clarification though, when you call out that it will create a date in the local time zone - actually the Date object always reflects the local time zone. You can't place it in another time zone, and even if you initialize it with a UTC timestamp, it will still reflect back the local time zone in most of the functions. Internally it tracks UTC by the numeric timestamp, and there are functions that expose UTC values explicitly, but everything else is local.Alum
@MattJohnson mentioned you and your clarification in answer. I hope you don't mind :)Drawl
Sure. :) Two other minor corrections to your post. JS uses the ISO8601 proleptic Gregorian calendar - so definitively NO, year 1 was not a leap year. With regard to DST in year 1, actually JS (ES5 anyway) will lie and use the current DST rule for all years.Alum
One question about first correction (ISO8601 proleptic Gregorian calendar) are we sure that all counties all over the world where using Gregorian calendar on year 1? My concern here is that from JS point of view it is not a leap year. But are we sure that people that lived in year 1 had 365 days in year? ( I mean all over the world, not Europe only ).Drawl
No, they were not, or we can't be sure. There were other various calendar systems in place then (or not). The Gregorian calendar phased in slowly start in 1582. JS (and most others) use the the ISO-8601 calendar, which is a proleptic Gregorian calendar. That means it acts as if this calendar was always in effect, even though we clearly know that it was not. In other words, JavaScript's "year 1" was 2014 of our years ago, but it is not the same as a "year 1" that might have been on some other calendar in use at that time.Alum
Is this your way of saying: "It's a mess"?Polyandry
This is a good answer but it would be better if you'd integrate those "updates" into a single, flowing narrative.Kaohsiung
WARNING! This date will be created in your current time zone!!! So be careful using it! Wrong! Date will be displayed (converted to a string) in your local timezone. But it doesn't mean it will be created that way.Pursuer
B
40

Use setFullYear - this is the Y2K issue with JavaScript.

var d = new Date(); d.setFullYear(1);
document.write(d);
Backchat answered 30/4, 2015 at 12:46 Comment(3)
How retro :) Threw in a document.write for nostalgic purposes too!Loftin
@RGraham im just doing that for the snip.Backchat
I know, just thought it was fitting for a Y2K issueLoftin
B
3

You can use the string version of the constructor:

console.log(new Date("0001-01-01"));
Blackandwhite answered 9/9, 2018 at 15:28 Comment(2)
Wait, did you just steal James Aylett's answer from #52246386 ;-)Dreamy
@DanielF - LOL! (Lurkers who may not get Daniel's joke: No, I posted there as well, but deleted it in favor of posting here when Raja found the dupetarget.)Blackandwhite
T
2

The (deprecated) Date.setYear method sets the year for a specified date, but note that:

If yearValue is a number between 0 and 99 (inclusive), then the year for dateObj is set to 1900 + yearValue. Otherwise, the year for dateObj is set to yearValue.

var theBigDay = new Date();

theBigDay.setYear(96);   // sets year to 1996
theBigDay.setYear(1996); // sets year to 1996
theBigDay.setYear(2000); // sets year to 2000

You should use Date.setFullYear method nevertheless. The other method is deprecated.

Tomkin answered 30/4, 2015 at 17:33 Comment(0)
D
0

when handling JavaScript date objects you have to specify the full year for ex, 1950 and not 50. It is mentioned in the doc. So the code should be as Daniel has said also,

d = new Date(); d.setFullYear(1);
console.log(d);
Discoverer answered 30/4, 2015 at 12:52 Comment(5)
um numeric literal 0001 is octal for 1Backchat
The values 1 and 0001 are identical.Ody
How exactly is this any different from Daniels answer?Intracellular
@Intracellular well one logs into console while the other writes into a document. :PLuscious
@Luscious Regardless, it should be a comment and not an answer.Intracellular
P
0

Actually, you can use the Date constructor for years whose absolute value is below 100, by using the negative year instead of the positive one, and then setting it back to positive using the reliable .setFullYear() / .setUTCFullYear() methods. This is because the issue of getting 20th or 21st century years in the case of historical ones manifests itself only for under 100 positive years. While for a basic usage this works without problems, care should be taken when using the new Date(...) constructor to add or subtract time at object creation moment, since you'd want to switch the operation sign accordingly as well. Also, if the desired historical year is negative in the first place and you need to add or subtract from it at construction time, the matter suffers further complications.

Therefore, to avoid any confusion and be clear and consistent about things, using the extended form of .setFullYear() / .setUTCFullYear() and .setHours() / .setUTCHours() to set the entire date and time parts after the object construction should be an optimal alternative and present no drawbacks whatsoever, while also being similar to setting things at construction time.

Below there are examples for each of the two methods mentioned above and both local and UTC dates (an optional 365 day or 31536000000 ms year is "added" in all cases, to illustrate if and how it changes things):

<!DOCTYPE html>
<html>
<body>
  <h2>JavaScript Historic Dates Problem</h2>
  <p>Construct negative dates and switch them to positive (1) or <br>Set the full date and time parts separately (2)</p>
  <p id="examples"></p>
  <script>
    var loc1 = new Date(- 37, 11, 24, 10, 33, 30, - 31536000000); loc1.setFullYear(- loc1.getFullYear());
    var utc1 = new Date(Date.UTC(- 37, 11, 24, 10, 33, 30, - 31536000000)); utc1.setUTCFullYear(- utc1.getUTCFullYear());
    
    var loc2 = new Date(); loc2.setFullYear(37, 11, 24); loc2.setHours(10, 33, 30, 31536000000);
    var utc2 = new Date(); utc2.setUTCFullYear(37, 11, 24); utc2.setUTCHours(10, 33, 30, 31536000000);
    
    document.getElementById("examples").innerHTML = "LOC1: " + loc1 + "<br>UTC1: " + utc1 + "<br>LOC2: " + loc2 + "<br>UTC2: " + utc2;
  </script>
</body>
</html>
Particulate answered 1/6, 2022 at 9:57 Comment(0)
M
0

If it can help you, to obtain the date 0001-01-01 00:00:00 in backend from frontend, I used the result of the associate timestamp in front which is: -62135773200000

For Example:

var dataToSend = {
    "user": "Me",
    "content": "Hello World",
    "date": -62135773200000 // only way I found in front-end for 0001-01-01 00:00:00
};

I hope it will help :)

Muir answered 24/1 at 10:44 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.