标签云

微信群

扫码加入我们

WeChat QR Code

I've seen so many different standards for the JSON date format:"\"\\/Date(1335205592410)\\/\"" .NET JavaScriptSerializer"\"\\/Date(1335205592410-0500)\\/\"".NET DataContractJsonSerializer"2012-04-23T18:25:43.511Z"JavaScript built-in JSON object"2012-04-21T18:25:43-05:00" ISO 8601Which one is the right one? Or best? Is there any sort of standard on this?


There is no date format in JSON, there's only strings a de-/serializer decides to map to date values.

2019年07月24日41分13秒

strings, numbers, true, false, null, objects and arrays

2019年07月23日41分13秒

However, JavaScript built-in JSON object and ISO8601 contains all the information to be understand by human and computer and does not relies on the beginning of the computer era (1970-1-1).

2019年07月24日41分13秒

Perhaps this should be changed to ask for the best convention, since the answers herein dismiss the question.

2019年07月24日41分13秒

What you called "JavaScript built-in JSON object" is also ISO8601-compliant.Standard allows for specifying decimal fraction of a second and for two ways of describing time zone.See W3C's note.

2019年07月24日41分13秒

This is also the preferred representations according to ECMA: JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}"

2019年07月24日41分13秒

I would add another important reason to the list: it's locale-independent. If you had a date like 02-03-2014 you'd need additional information to know if it refers to the 3rd of Feb or the 2nd of March. It depends on whether US-format or other format is used.

2019年07月24日41分13秒

upvote for mentioning and linking xkcd :D ajorquera I usually use momentjs for this. I've also seen issues with IE in this regard

2019年07月24日41分13秒

Regarding the second point, it does not sort correctly after the year 10000. We do have almost 8000 years to come up with a new format though, so it's probably not an issue.

2019年07月24日41分13秒

Actually, Erfa, since - comes before digits in ASCII, it will sort just fine until the year 100,000. ;P

2019年07月24日41分13秒

Ugh, I'd expect an error... But at least firefox does stringify it... well, it's not part of the JSON standard so I wouldn't feed a Date object to a JSON serializer - it might not work in all browsers. Apparently it's a common idea for JSON serializers to use a toJSON() function if it exists on an unknown object. At least Firefox does that for Date objects and Date objects do have such a method.

2019年07月24日41分13秒

stackoverflow.com/questions/10286385/… - let's see if someone knows why FF behaves like that.

2019年07月24日41分13秒

If you go this route, make sure you don't need to deal with dates earlier than 1970!

2019年07月24日41分13秒

As BenDolman said, this "solution" doesn't deal appropriately with dates prior to Jan 1st, 1970 (Epoch). Also, there is a reason ISO8601 exists in the first place. Here on Earth we have things called "time zones." Where is that in milliseconds? JSON may not have a standard for dates, but dates exist outside of JSON, and there is a standard for that. funroll's answer is the correct one (see also: xkcd.com/1179).

2019年07月24日41分13秒

It is maybe also worth mentioning that (milli)seconds from 1970 isn't predictable for dates in the future because we have leap seconds. So I wouldn't use if for inter-process communication and data storage. It is however nice to use internally in a program since it can be stored in a single integer which gives you some performance benefits.

2019年07月23日41分13秒

mlissner but that's an opinion on which one is best. ISO-8601 is a standard, but it's not the standard for JSON (even though I'd be inclined to use it); for example, Microsoft decided not to use it (msdn.microsoft.com/en-us/library/…). The best practice is to stick with one (sensible) convention , whatever that is. As I stated in the answer, the best way of handling this is to define a date parsing utility function that can handle the expected formats. If you integrate with systems that use different formats, the function should handle each case.

2019年07月24日41分13秒

RussCam, we can go back and forth, but if somebody is asking the best way to encode dates in JSON, they're asking how to format dates when they make JSON (and the answer is generally ISO-8601). You're answering the opposite question: how to consume JSON dates once they're already made (though your advice is sound).

2019年07月24日41分13秒

The JSON schema specification actually says that dates that are verified by a schema must be in 8601 format.

2019年07月24日41分13秒

gnasher729 do you have a link?

2019年07月24日41分13秒

vallismortis - That is a draft specification for defining a schema for a given json structure exchanged between parties, not the format for dates in the json specification. I'm going to revise my answer as based on the comments, it doesn't appear I've made it clear enough

2019年07月23日41分13秒

This is also the format produced by Date().toISOString() and Date().toJSON(), with the limitation that Date doesn't track a timezone value, and hence always emits the timestamps in the UTC (Z) timezone. The value can be parsed using new Date("...") and Date.parseDate.

2019年07月24日41分13秒

I wouldn't use that format, but the rest of the info you provided is very useful, thank you!

2019年07月24日41分13秒

Correct! The JSON Data Interchange Syntax does not specify the standard: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf but in practice, ISO 8601 compatible formats are more desirable across platforms including JavaScript runtime.

2019年07月24日41分13秒

Comments have been moved to chat.

2019年07月23日41分13秒

Now you have 2 problems: Which epoch should you choose, and which milliseconds should you count? Probably the most common choice is Unix time (1970-01-01T00:00:00 UTC and SI milliseconds except for those which fall within a leap second), but of course that makes future times undefined.

2019年07月24日41分13秒

So how do you represent microseconds? RFC3339 works fine with any precision, you'll have a reader that parses the timezone and gives you the right time stamp, and it's additional information. Calendar apps usually care about time zones.

2019年07月24日41分13秒

Timezone is not a UI concern, unless you don't mind missing your next flight. Flights are posted in local time and follow specific rules for DST changes. Losing the offset means losing important business information

2019年07月24日41分13秒

Some further counterarguments include the ability to represent times before 1970 (assuming that particular epoch), and JSONs tendency to be somewhat human-readable.

2019年07月24日41分13秒

I doubt anyone will be using json in the year 10000, or even that by that time the year 10000 will still be year 10000. But if both of those things are still true by then, the format can simply be expanded to contain a 3 digit century component. So I'd say people can safely stick with RFC 3339, at least until the year 9900

2019年07月24日41分13秒

downvoters: According to Why is voting important? you should downvote if a post contains wrong information, is poorly researched, or fails to communicate information. Please explain for which one of these reasons you've downvoted this answer.

2019年07月24日41分13秒

Marten Two things. 1. You are never owed an explanation for downvotes, though I understand it can be helpful. 2. I did not downvote your answer, but I would guess that people don't like your answer because they think it is the wrong way to do this. That would qualify it as "Wrong information" since the question is looking for the best way to do something

2019年07月24日41分13秒

I did not downvote you, but I can certainly understand how "invent yet another poorly specified format" (which is basically what you're saying) would be seen as wrong or poorly researched.

2019年07月23日41分13秒

Phil, UTC is not really a time zone (there is no place on earth which uses "UTC" as its official time zone), it's a time standard. Also time zone offsets are quite unpredictable. There is no way to say if in 2025 "12:00 Moscow time" is still "9:00 UTC" like it is today, it has been changed a couple of times during the last 30 years. If you want to express a future local time you need true time zones.

2019年07月23日41分13秒