Re: JSON / ASP.NET AJAX Dates support in PostgreSQL

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:
>>>>       Is there an easy way to convert JSON data containing ASP.NET AJAX Dates
>>>>       into PostgreSQL timestamp?
>>>>
>>>>       I have this kind of JSON data:
>>>>
>>>>       {
>>>>           "PurchaseOrder" : "4500000000",
>>>>           "CreationDate" : "\/Date(1672358400000)\/",
>>>>           "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):

"
We're pretty much satisfied with this solution to the date problem, but 
of course for the moment very few serializers and parsers support that 
convention. It would be great if this could become the consensus across 
the industry.
"

NOTE: This is from Friday, January 18, 2008

I'm going to go out on a limb and say whatever JSON parsing Postgres is 
doing does not recognize this format.



> 
>          hp
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com