Why is this JSON giving me parse errors? I could swear I've done this a hundred times before without issue.
[[0,0,0,new Date(1364068990245)],[0,0,0,new Date(1364068940075)]]
If that's literal JavaScript, as in this:
var myArray = [[0,0,0.......]];
Then it should be fine, your error must be coming from somewhere else.
If it's a string that you're treating as JSON, as in this:
var myArray = JSON.parse("[[0,0,0.........]]");
Then you can't have new Date (or indeed any function call) and it should be just a number that you then parse into a date.
Because the new operator isn't part of JSON. Your example is a valid fragment of a JavaScript file, but it correctly results in an error when parsed as JSON. Dates should be serialized as strings (ideally, as ISO-8601 strings that will be accepted by the Date constructor, but I suppose numbers are tolerable as well).
That's not JSON, there are no dates in the JSON format.
Ref: http://www.json.org/
Some JSON parsers have extended the standard with this way of representing a date:
"[[0,0,0,/Date(1364068990245)/],[0,0,0,/Date(1364068940075)/]]"
If the parser that you use doesn't support that, you have to transmit them as a different data type, for example numbers, and then convert them to dates after parsing the JSON:
"[[0,0,0,1364068990245],[0,0,0,1364068940075]]"
Related
I'm trying to write to Firestore all the prices from different stocks. Structure should look something like this (although this might not be the best fitted for it, still thinking of it as in SQL) :
const d1 = new Date();
const result = d1.getTime();
console.log('Epochtime',result);
database.collection("stock1").doc("exchange1").collection(date).doc('prices').set({"price":"price_value"})
Now the problem is that I can't create a collection with a name that's a variable that contains date. I tried all the different types of it and I presumed that epoch time should work, as this is a number like: 1636213439908. I always get the error: Value for argument "collectionPath" is not a valid resource path. Path must be a non-empty string. Although the exact same variable can be written as a value in a collection. So not sure what am I doing wrong here.
Document IDs in Firestore must be strings, so you'll have to convert the data to a string. While date.toString() will work, I highly recommend using a ISO-8601 format for the dates, such as date.toISOString(). These formats are designed to be both humanly readable and machine sortable.
I'm planning to collect some data over a few months (daily) for further processing and representation in JavaScipt (probably using any js libraries, such as d3.js, etc. I don't know which one yet). The data will consist of:
date
one integer
one decimal number
Which file/data format would you recommend for recording data for subsequent work with JavaScript?
I think CSV would be more appropriate here because it sounds like it's just going to be a big long list of datapoints.
JSON would work, just like XML or any other system would work, but as much as I love JSON, it is not necessarily well-suited to the job:
JSON will be space-inefficient. It requires lots of punctuation characters.
JSON will be memory-inefficient. To add anything to the JSON file you'll need to:
Read the entire file as one long string
Parse that long string as JSON, saving it in memory as a big hash or array
Insert your new data
Re-encode the big hash or array as one long string
Overwrite your old file with that new long string
JSON will be harder to read... unless it's stored in "pretty" format, in which case it'll be even more space-inefficient.
CSV requires much less superfluous punctuation, and you can append a new line of data to the end of your file without needing to read and write the entire thing.
Consider:
JSON (not pretty):
{"01012016":[42,0.8675309],"01022016":[12,9.87654321]}
JSON (pretty):
{
"01012016":[
42,
0.8675309
],
"01022016":[
12,
9.87654321
]
}
CSV:
01012016,42,0.8675309
01022016,12,9.87654321
Javascript doesn't have a built-in CSV parser in the way it has JSON.parse... because parsing CSV is really easy! Here's just one of many ways of doing it:
var splitByLine = myCSVString.split("\n");
var splitByLineAndComma = [];
splitByLine.forEach(function(line){
splitByLineAndComma.push(line.split(","));
});
I would default to using JSON, which is not only lightweight, but JavaScript also has a built in, easy-to-use JSON parser: JSON.parse.
JSON is a collection of name/value pairs, which sounds ideal for the use case you've suggested:
[
{
"my-date": 1451744353495,
"my-int": 42,
"my-decimal": 3.1415926535
},
{
"my-date": 1451744353496,
"my-int": 43,
"my-decimal": 2.7182818284
},
{
"my-date": 1451744353497,
"my-int": 44,
"my-decimal": 1.4142135623
}
]
If you have JSON as a string, just pop it into JSON.parse, and you're ready to roll with a shiny new JavaScript object:
var obj = JSON.parse(str);
obj[0]["my-int"] === 42; // true
I am just trying to parse a Json document with a field Date like this:
´ death':Date('2007-03-17T04:00:00Z') using
com.mongodb.util.JSON.parse(document)
There is an exception when the value Date is encountered. Any help?
The key here is whatever has exported the data has done it wrong. Possibly someone has run something from the MongoDB shell and redirecting console output to a file. That is basically "doing it wrong".
There is a concept called MongoDB Extended JSON and has in fact been picked up in a few other areas, notably the EJSON project.What this tries to do is make sure that any exported JSON maintains "type" information to the BSON type identifier ( or other Object Type, in the purpose of EJSON ) so that a similar "extended JSON" parser can "re-construct" the object to it's intended form.
For a "date" object, the intented JSON representation is this:
{ "death": { "$date": "2007-03-17T04:00:00Z" } }
Since com.mongodb.util.JSON.parse is enabled with knowledge of the Extended JSON spec, then any such JSON contruct will result in a correct date object being constructed from the parsed data.
So what you have right now is just a "string". In fact, if it is not "quoted" like this:
´ { "death" : "Date('2007-03-17T04:00:00Z')" }
Then it is not in fact even valid JSON and would even need to be manipulated to a correct form before even a basic JSON parser would not error. At any rate, the result is just a "string" still, so you would need to make a regex match for the numerical data, then pass that to a date object construct.
Clearly the "best" thing to do here is to fix the "export" source of the data so that it is doing this date parsing to JSON in the correct extended way. Then the parser you are using will do the right thing.
I've seen so many complicated questions in SO whether or not some complicated structure is considered to be valid JSON.
But what about something on the other end of the spectrum?
"12345"
Is the above valid JSON?
Yes, in most contexts. It is valid JSON syntax representing a JSON value.
The confusion around this comes from Douglas Crockford's RFC 4627, which originally defined the application/json internet media type in 2006. It said that:
A JSON text is a serialized object or array.
However, as Crockford explained in a post in 2013 (unfortunately deleted with rest of Google+, but archived here):
JSON is just a grammar, and the grammar includes numbers and strings. Uses of JSON must necessarily be more restrictive. RFC-4627 is one possible use, and was never intended to be the standard for JSON itself.
The example string is a valid JSON value, but it would have been incorrect to use it as the full "JSON text" body of an application/json HTTP response. However, that's no longer true: RFC-4627 was obsoleted in 2014 with the publication of RFC 7159, which lets you use any JSON value:
A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array.
A "standard for JSON itself" was also published in 2013, as ECMA-404, and JSON was also defined in edition 5.1 of the ECMAScript (JavaScript) specification ECMA-262. These specifications and most parsers allow any JSON value as a complete JSON text, even if it's just a simple string.
As of 2014, RFC 7159 obsoletes the older JSON RFCs, and declares that any JSON value is valid JSON text and valid application/json content - including strings. However, it also points out the incompatibility issue with older JSON implementations:
Note that certain previous specifications of JSON constrained a
JSON text to be an object or an array. Implementations that
generate only objects or arrays where a JSON text is called for
will be interoperable in the sense that all implementations will
accept these as conforming JSON texts.
Its a valid JSON string, but its not a JSON object.
See http://www.json.org/
At the time this question was written, this would not have been a valid JSON text. It would have been a valid string that could appear as part of a JSON text.
The original specification said:
A JSON text is a serialized object or array.
… meaning that the top level had to be {} or []. You couldn't dive straight in with a string.
The latest specification says:
A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array.
So now any value, including a string, can be a complete JSON text and "12345" is now valid.
You can simply check what JSON.parse can handle:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#examples
This is all valid JSON:
JSON.parse('{}'); // {}
JSON.parse('true'); // true
JSON.parse('"foo"'); // "foo"
JSON.parse('[1, 5, "false"]'); // [1, 5, "false"]
JSON.parse('null'); // null
jQuery.param({foo: 1}); // => "foo=1" - SUCCESS!
jQuery.param({bar: new Date()}); // => "" - OUCH!
There is no problem with encodeURIComponent(new Date()), which is what I would have thought param is calling for each member.
Also, explicitly using "traditional" param (e.g. jQuery.param(xxx, true)) DOES serialize the date, but alas, that isn't of much help since my data structure isn't flat.
Is this because typeof(Date) == "object" and param tries to descend into it to find scalar values?
How might one realistically serialize an object that happens to have Date's in it for $.post() etc.?
You're probably going to want the date transformed into a string, since that's what it's going to have to be on the wire anyway.
$.param({bar: new Date().toString()});
Now you may want it formatted in some particular way so that your server gets something it can parse. I think that the datejs library has support for formatting, or you could roll your own by picking out pieces of the date with getDate(), getMonth(), getYear() etc.
If you work with Microsoft products on the server side you should take in consideration, that Microsoft serialize Date as a number of milliseconds since UTC, so as a number. To be more exact, the serialization string look like /Date(utcDate)/, where utcDate date is this number. Because JSON supports the backslash as an escape character you should use code like following to serialize a Date object myDate:
"\/Date(" + Date.UTC(myDate.getUTCFullYear(), myDate.getUTCMonth(),
myDate.getUTCDate(), myDate.getUTCHours(),
myDate.getUTCMinutes(), myDate.getUTCSeconds(),
myDate.getUTCMilliseconds()) + ")\/"
I think this is a jQuery bug in the following context:
jQuery 1.4.2 (1.3.2 works)
new methods added into Date.prototype