On 2023-04-15 09:12:41 -0700, Adrian Klaver wrote:
> On 4/15/23 03:46, Peter J. Holzer wrote:
> > On 2023-04-14 10:44:08 -0700, Adrian Klaver wrote:
> > > On 4/14/23 9:31 AM, Peter J. Holzer wrote:
> > > > On 2023-04-13 10:07:09 -0500, Ron wrote:
> > > > > On 4/13/23 09:44, Sebastien Flaesch wrote:
> > > > > "LastChangeDateTime" : "\/Date(1672692813062+0100)\/"
> > > > >
> > > > > Warning: Note the backslash before the slashes!
> > > >
> > > > That's a Noop. According to RFC 8259, "\/" is the same as "/" (no idea
> > > > why they even specified that - it seems quite pointless).
> > >
> > > It is a cheat explained here:
> > >
> > > https://weblogs.asp.net/bleroy/dates-and-json
> >
> > Yes, but it needs a specialized JSON parser to note that. As they write:
> >
> > > Of course, a parser that doesn't know about this convention will just
> > > see a string,
> >
> > And not only will it just see a string, it will output a string that's
> > indistinguishable from a string with the input
> > "/Date(1672692813062+0100)/". So any code after the parser can't detect
> > those extra backslashes. (This would include for example the object_hook
> > in the Python json Decoder which gets the decoded strings, not the raw
> > strings).
>
> I would encourage you to read the whole post, it is short. Bottom line, this
> is a cheat MS created for the Microsoft Ajax Library. Their hope was(from
> the post):
Yes, I got that.
[...]
> I'm going to go out on a limb and say whatever JSON parsing Postgres is
> doing does not recognize this format.
Exactly. This was my point. Nor is any other JSON parser (except the one
which invented that cheat of course) likely to recognize it. And it's
sort of hard to add to existing parsers without breaking app
compatibility. In short: I don't think adding that to Postgres is a good
idea.
hp
PS: I do appreciate it as a hack, though.
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
