How to format BC dates (like "-700-01-01")? - javascript

How to format ISO dates BC with Moment.js?
moment("-700-01-01").year(); // 700 (WRONG)
moment("-0700-01-01").year(); // 700 (WRONG)
moment("-000700-01-01").year(); // -700 (RIGHT)
For some reason a year notation with 6 digits works. Is that the "right" way? Why doesn't notation like "-700-01-01" work?

This isn't a Moment.js-specific problem; the same happens if you attempt to initialise a Date() object with the string you're using as well. If you create it as a Date() object first and manually assign the year using setYear() it does accept a date of -700:
var date = new Date();
date.setYear(-700);
moment(date).year();
> -700
However as Niels Keurentjes has pointed out, date calculations this far back get quite complicated and may not be at all reliable.
If you want "-700-01-01" you can configure the year, month and day separately:
date.setYear(-700);
date.setMonth(0);
date.setDate(1);
console.log(date);
> Fri Jan 01 -700 11:53:57 GMT+0000 (GMT Standard Time)
As to whether the 1st day of the 1st month in 700BC was actually a Friday... you'll have to look that one up yourself.

You can also
moment('0000-01-01', 'YYYY-MM-DD').set('y', -700)

in your example the minus sign is also used as separator between years, month and days. As you point out in the comment of the answer of James, using coma as separator helps to distinguish.

moment can display expanded years using the YYYYYY notation. This feature is recorded in the moment.js display documentation and elaborated upon in the ECMAscript documentation.

Related

Date.prototype.toLocaleDateString() problem

I'm working on a graphical listing of Roman emperors and ran into the following problem:
The birth and death dates are stored in a JSON as a string. e.g. Julius Caesar:
"start":"-000100-07-12"
If I use the Date object
console.log(new Date(caesar.start))
... via console.log it works:
//Date Object Thu Jul 12 -0100 00:53:28 GMT+0053 ...
but if I now want to render the object as a string with
console.log(
new Date("-000100-07-12")
.toLocaleDateString("en", {year : "numeric", era: "short"})
);
console.log gives me
"101 BC" instead of "100 BC"
the problem is easily reproducable.
I only found a similar description
for a different technology.
However, the problem seems to be the same.
A fix would be to write a custom toLocaleDateString function, because getFullYear(), getMonth() work as expected.
Has anyone had similar experiences, or a solution to the problem? I guess handling dates before 1582 is a bit hooky.... maybe it has to do with the fact that there is no year 0?
Looks like the problem is in toLocaleDateString.
But separate methods work as expected
For example
date.getDate(); // 12
date.getFullYear(); // -100
date.getMonth(); // 6 (getMonth() starts with 0)
You can get the same format with this methods.
According to the ISO 8601 standard "-000100-07-12" represents 12th July 101 BCE and the date appears to be being parsed correctly.
It's just that the standard doesn't match our expectations as we almost always deal with positive years.
Unfortunately I'm unable to see what the "Cause" of the linked Oracle error is so it may be the same "issue"

Javascript dates: a nightmare

I understand that dealing with dates, in any environment, could be quite confusing, but I'm in a nightmare with a function that should be a trivial job.
I want to manipulate in different ways some dates, but I get errors or wrong results.
I report hereafter a very simple example made to test the execution; the goal here is to get the current month beginning date, just to show what happens:
function DateAdjust() {
var newdate = new Date(); //1: 2018-12-12T21:00:20.099Z
newdate = newdate.setDate(1); //2: 1543698020099
newdate=Date(newdate); //3: Wed Dec 12 2018 21:01:43 GMT+0000 (Ora standard dell’Europa occidentale)
var d = newdate.getDate(); //4: newdate.getDate is not a function
}
4 lines, 3 unexpected results (as shown by Firefox's debugger):
1. the starting date has no day-of-week and no timezone
2. setting the day, result is transformed in milliseconds (why?); I do not know if it is correct.
3. reconverting in string gives the original date, unmodified (why?) but with week day and timezone
4. trying to get the day value an error is thrown (why?)
My environment:
Win 7 32bits SP1
Firefox 63.0.3 (32 bit)
jquery-2.2.4.min.js
I know these questions are boring, but hope someone will find few minutes to clear my mind.
Regarding line 1, the Z at the end is the timezone designation for UTC in ISO 8601 (see Wikipedia).
If the time is in UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or "144515Z".
Regarding line 2 see the MDN article on setDate (emphasis mine):
The number of milliseconds between 1 January 1970 00:00:00 UTC and the given date (the Date object is also changed in place).
So you can see the 'correct' behavior you probably expect simply by ignoring the return value:
var newdate = new Date(); //1: 2018-12-12T21:00:20.099Z
newdate.setDate(1); //2: 1543698020099
console.log(newdate); //3: 2018-12-01T21:00:20.099Z
Regarding line 3, see MDN article on Date (emphasis mine):
Note: JavaScript Date objects can only be instantiated by calling
JavaScript Date as a constructor: calling it as a regular function
(i.e. without the new operator) will return a string rather than a
Date object; unlike other JavaScript object types, JavaScript Date
objects have no literal syntax.
Regarding line 4, the above also explains this error, since newdate is now a string rather than a Date object.
For what it's worth, I agree with the other commenters. JavaScript's date functions are pretty messy compared to many other modern languages. I strongly recommend using a library like moment, luxon, or date-fns. It'll make your life much easier.
I do recommend using moment.js
But there are 2 problems with your code:
1-
newdate = newdate.setDate(1);
setDate mutates newDate in place, and return it in miliseconds, not a new Date object. If you just want to set the date, do this instead:
newdate.setDate(1);
2-
newdate=Date(newdate);
Not realy sure why you are trying to get a new Date object, but you need the new, otherwise it will just be a string
newdate= new Date(newdate);
Fixing problem 1 should eliminate the need for the code of problem 2
var newdate = new Date(); // 1
console.log(typeof newdate, newdate); // object Wed Dec 12 2018 23:00:44 GMT+0200 (Eastern European Standard Time)
newdate = newdate.setDate(1); // 2
console.log(typeof newdate, newdate); //number 1543698085383
newdate=Date(newdate); //3
console.log(typeof newdate, newdate); //string Wed Dec 12 2018 23:04:44 GMT+0200 (Eastern European Standard Time)
var d = newdate.getDate(); // 4
console.log(typeof d, d); //
Date type is assigned to the object.
number is assigned to newdate. which is ticks
returns string
string.getDate() is not defined, so undefined.
hope it helps.

Moment JS Parse strange behaviour

I'm using moment.parse String+Format method
when I call moment("=min(C2:C4)", 'DD/MM/YYYY') it evaluates to valid date
Sun Apr 02 2017 00:00:00 GMT+0300 (FLE Daylight Time)
I can't understand how moment parses "=min(C2:C4)" to valid date. Just wonder, some one can explain.
From Moment.js docs:
Moment's parser is very forgiving, and this can lead to undesired/unexpected behavior.
Short answer: because of your expected loose format, moment parses the 2 as the day and the 4 as the month.
Long answer:
Visualizing this might be easier if you run your command in a console and view the results. I'd recommend taking a look there first, and I'll explain the important parts below.
Date string vs. format
You've specified your string as "=min(C2:C4)" and your format as DD/MM/YYYY, so moment is looking for a date in that general format: a day followed by a month followed by a year.
moment._pf.unusedTokens[]
This is an array and has one value, 'YYYY'; the parser did not find a year, but it did find a day and a month... hmmm.
moment._pf.unusedInput[]
This tells us more - an array with three values:
1. '=min(C'
2. ':C'
3. ')'
Looks like moment found the 2 and the 4 to match day and month. You'll find these values in the moment._pf.parsedDateParts array.
So, that should explain why the date is April 2, 2017. The month of 3 (this is the finalized month, not the actual value parsed. Months are zero-indexed, so it's back to "4") and the day of 2. No year was given, so moment assumes it's the current year. No time was given, so it assumes the start of the day.
If you don't want this behavior you should pass a 3rd / last param as true (strict matching). Check http://momentjs.com/docs/#/parsing/string-format/ for more details.

Convert ISO Date string to date in JavaScript

Need help to convert exactly from ISO Date string to Date:
I have an ISO string date: "2016-01-23T22:23:32.927".
But when I use new Date(dateString) to convert Date, the result is wrong:
var date = new Date("2016-01-23T22:23:32.927");
The result is: Sun Jan 24 2016 05:23:32 GMT+0700. It's not true. I want the date is 23 not 24.
Please help me. Thanks a lot!
You need to supply a timezone offset with your iso date. Since there isn't one, it assumes the date to be in GMT and when you log it out, it prints it in the timezone of your browser. I think that if you pass "2016-01-23T22:23:32.927+07:00" to new Date() you would get the value you are expecting.
JavaScript environments (browser, node,...) use a single timezone for formatting dates as strings. Usually this is your system's timezone. Based on the output you get, yours is GMT+0700.
So what happened:
The string you passed as ISO format to the Date constructor doesn't specify a timezone. In this case it is treated as UTC.
When you then output the date (I'll assume with console.log), it is converted to the timezone of your environment. In this case 7 hours where added.
If that doesn't suit you, you can change the way you output the date. This depends on what output you want, e.g.:
If you just want the UTC timezone again, you can use date.toISOString().
If you want to output it in another timezone, you can call date.getTimezoneOffset() and figure out the difference between both timezones. You'd then probably need to get the individual date parts and add/subtract the timezone difference accordingly. At this point you could consider using an existing library, taking into account their possible disadvantages.
If you're willing and able to add a dependency, I recommend using moment.js for this. It makes date handling in Javascript much more straightforward and a lot safer, and fixes your specific problem right out of the box.
To do this, 1st load it from a CDN, e.g. Moment.JS 2.14.1 minified. Then use it as follows:
var date = moment("2016-01-23T22:23:32.927");
console.log(date);
// output: Sat Jan 23 2016 22:23:32 GMT-0500
...i.e. your desired result :)
Here's a jsfiddle demonstrating this.
Use date.toUTCString()
it'll give you 23 instead of 24 as it Convert a date object to a string, according to universal time

Javascript: Difference between `new Date(dateString)` vs `new Date(year, month, day)`

Referencing to the accepted answer on this question How do I get the number of days between two dates in JavaScript?. I see, in the function parseDate:
function parseDate(str) {
var mdy = str.split('/')
return new Date(mdy[2], mdy[0]-1, mdy[1]);
}
He is doing this:
var mdy = str.split('/')
return new Date(mdy[2], mdy[0]-1, mdy[1]);
i.e. splitting the passed date into month, day and year and then passing it on to Date like new Date(year, month, day) while he could simply do new Date(str) and it would have returned the same result (Wouldn't it?). Can anyone please explain the difference between both the ways?
Update: Test results:
var str = '1/1/2000'
var mdy = str.split('/')
console.log( new Date(str) ) // Sat Jan 01 2000 00:00:00 GMT+0500 (Pakistan Standard Time)
console.log( new Date(mdy[2], mdy[0]-1, mdy[1]) ); // Sat Jan 01 2000 00:00:00 GMT+0500 (Pakistan Standard Time)
No, they're not the same (even assuming you'll subtract one month later: he's doing mdy[0] - 1) because new Date(str) is required (by standard, see §15.9.4.2) to accept only date in a specific format ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ, see also this post, I won't repeat myself here):
If the String does not conform to that format [ISO 8601] the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
Please note (as pointed out by Royi in comments) that also RFC 2822 should be supported (according to MDN) but it's not mentioned in JavaScript specifications and Internet Explorer doesn't officially support it (see MSDN, it can parse something similar but it's not the same).
In that code they're parsing using a specific locale rules (MM/DD/YYYY, I suppose en-US locale but it's not only one). To be honest I wouldn't even use that code for parsing (because yes, actually it'll be broken for a different locale: even separator used for splitting is not "locale safe"). Let me explain with an example:
You're using a proper configured date time picker (or <input type="date"/> when supported) you'll enter date according to your locale. For example in Italy (but in general in Europe) we write DD/MM/YYYY.
Now let's imagine that user picked 21 December 2014 (formatted as 21/12/2014 according to his locale).
With string splitting that code will fail (because it'll pick 21 as month number, obviously it's not valid). Even worse than that such errors may even go unnoticed (for example if user picks 1/2/2014 code will "think" it's 2nd Jan but user picked 1st Feb). Do you want to make it more complicate? Even new Date(str) may fail because it's browser dependent (and you can't really trust heuristic to be portable and safe).
If you're asking yourself "Then why they used such code?" I'd say that they used a quick workaround to support dates using en-US locale (probably because browser they used didn't support them with heuristic guess) but it's not something you should reuse.
Solution? Do not ever parse date by hand (unless you really and deep know what you're doing), use a good library (for example moment.js) for that because most assumption you may do about date formatting are...wrong.
I tried to enter your test code into jsperf.com, and the results on my machine are clear, and they say that you should not try to split the string.
I tried two tests for the test using a split string, and supprisingly, the split itself was not what was taking up the time.
Try for yourself at http://jsperf.com/date-from-string-or-dateparts

Categories

Resources