3 ms·
> That's why Microsoft got away with proprietary date formats in System.Text.Json. What's proprietary in it? It follows ISO 8601-1:2019 and RFC 3339 according
by cpx86 5y ago
> That's why Microsoft got away with proprietary date formats in System.Text.Json.
What's proprietary in it? It follows ISO 8601-1:2019 and RFC 3339 according to the docs.
- da_chicken 5y agoSorry, that should be System.Runtime.Serialization.Json. System.Text.Json is the newer class that replaced it. In .Net Framework 4.6 and earlier, the only built-in JSON serializer in the .Net Framework was System.Runtime.Serialization.Json.DataContractJsonSerializer. You can still see it. If you're on Windows 10, run Windows Powershell v5.1 and run: Get-Item C:\Windows\System32\notepad.exe | Select-Object -Property Name, LastWriteTime | ConvertTo-Json You'll see this output: { "Name": "notepad.exe", "LastWriteTime": "\/Date(1626957326200)\/" } Microsoft didn't fix their weird JSON serialization until quite late. They may have back ported it to the .Net Framework, but they've deleted that documentation. Powershell v6 and v7 include the newer classes that are properly behaved. This is why Json.NET used to be so popular and ubiquitous for C# and ASP applications. It generated JSON like most web applications do, not the way Microsoft's wonky class did. Indeed, I believe it may be what System.Text.Json is based on.
- cpx86 5y agoOh that one - yeah I've always steered clear of DataContractJsonSerializer. Never understood why they did it so weird. To be fair, RFC 3339 wasn't even published back when this class was implemented (in .NET 3.5) so I guess they just went with whatever worked for their needs. ¯\_(ツ)_/¯
- da_chicken 5y agoI'd be quicker to believe that it's because 2007 was still in the middle of Steve Ballmer's Microsoft, where embrace-extend-extinguish was their de jure practice.