DateTimeOffset.TryParse doesn't format a russian RFC Date in .Net 5.0 but it works in .Net 3.1. Why?

Question

This is my code:

using System;
using System.Globalization;

public class Program
{
    public static void Main()
    {
        CultureInfo cultureInfo = new CultureInfo("ru");
        DateTimeOffset dt;
        bool parseSuccess = DateTimeOffset.TryParse("Ср, 17 фев 2021 15:03:25 +0300", 
            cultureInfo.DateTimeFormat, DateTimeStyles.None, out dt);
        Console.WriteLine(dt.ToUniversalTime());
    }
}

Date String: "Ср, 17 фев 2021 15:03:25 +0300"

.Net 5.0 Output:

.Net 3.1 Output:

I need the output from 3.1 but in 5.0 and I've tried quiet a few solutions which didn't work and I'm not sure why. When I debug it, it says that the date is not a correct date format but then why does it work in 3.1 and not 5.0?

There's no `Russian RFC date`. That's a localized date literal with an offset — Panagiotis Kanavos, Feb 17 '21 at 14:42
Maybe the people at [ru.stackoverflow](https://ru.stackoverflow.com/) can give better feedback. — Cleptus, Feb 17 '21 at 14:46
Which OS are you targeting? I can confirm that `DateTimeOffset.Parse("Ср, 17 фев 2021 15:03:25 +030",CultureInfo.GetCultureInfo("ru-RU"));` works in .NET Old 4.7.2 , .NET Core 3.1, but fails in .NET Core 5 — Panagiotis Kanavos, Feb 17 '21 at 14:48
When you said `Russian RFC` were you referring to the [RFC1123](https://learn.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings#RFC1123) date? This format doesn't change by culture, so there's no Russian version. It's always GMT, in all .NET versions. `DateTimeOffset.Now.ToString("r",CultureInfo.GetCultureInfo("ru-RU"))` returns `Wed, 17 Feb 2021 14:59:58 GMT` — Panagiotis Kanavos, Feb 17 '21 at 15:01
@PanagiotisKanavos The version I'm targeting is .Net Core 5, yes it does work in 3.1 but I'm trying to get the 3.1 output in 5 because that's the desired OS version. Yes its the RFC1123 date. — ID10T_E330r, Feb 18 '21 at 05:20
@ID10T_E330r the string you posted isn't a valid RFC1123 date though. RFC1123 ends with GMT always. That's why the RFC1123 specifier, `r`, returns GMT. [This SO answer](https://stackoverflow.com/questions/54927845/what-is-valid-rfc1123-date-format) explains what the valid format is and contains references to the specifications. You'll have to use `TryParseExact` to parse this *non*-standard format. — Panagiotis Kanavos, Feb 18 '21 at 07:32
@ID10T_E330r the issues posted by Hans Passant explain what changed between versions and why - to get consistent behavior between Windows and Linux, .NET Core now uses the standard-based ICU globalization library. This is used by all Linux server, which suggests `Ср, 17 фев 2021 15:03:25 +0300` was generated by a *Windows* server — Panagiotis Kanavos, Feb 18 '21 at 07:35
@PanagiotisKanavos Yeah makes sense, its the way the device sends dates to the API — ID10T_E330r, Feb 18 '21 at 07:46
@ID10T_E330r in that case the device (whatever it is) may need fixing. It would have a problem calling *any* server. This date typically appears in HTTP headers which means servers, proxies and caches won't be able to understand caching/expiration dates. Is that what happens here? Do you have to parse the header because the server didn't understand it? — Panagiotis Kanavos, Feb 18 '21 at 07:56
@PanagiotisKanavos to be honest I'm not even sure, all I really know is that the date come in like `Ср, 17 фев 2021 15:03:25 +0300` and we need to convert it to `2021/02/17 12:03:25` — ID10T_E330r, Feb 18 '21 at 08:15
@ID10T_E330r in a header? A JSON body? A form POST? Headers will cost you and the customer, JSON is simply evil (the ISO8601 is the de-facto standard), form fields are "only" a pain for programmers. — Panagiotis Kanavos, Feb 18 '21 at 08:19

ID10T_E330r · Accepted Answer · 2021-02-18T07:51:08.920

2

I managed to find a solution to my issue thanks to @HansPassant GitHub Link.

From this link I was able to find some information from the Microsoft docs.

I added the code below to the .csproj file and it works.

 <ItemGroup>
    <RuntimeHostConfigurationOption Include="System.Globalization.UseNls"Value="true" />
 </ItemGroup>

edited Feb 18 '21 at 07:51

answered Feb 18 '21 at 07:31

ID10T_E330r

41
8

`` in the project file should be enough; no need to use a runtimeconfig.json file. – Yarik Feb 18 '21 at 07:37
@Yarik that's true, then there's no need for all the other information. – ID10T_E330r Feb 18 '21 at 07:50
You should probably fix the device(s) that produce the non-standard dates. If those appear in HTTP headers, caches, proxies and servers won't be able to parse caching/expiration periods and forward *all* traffic to your server. You'll end up paying for the device bug - both for traffic and deploying more servers to handle calls that weren't cached. Or, configure all proxies/servers in your control to handle this, so at least *you* don't have to pay – Panagiotis Kanavos Feb 18 '21 at 07:59

DateTimeOffset.TryParse doesn't format a russian RFC Date in .Net 5.0 but it works in .Net 3.1. Why?

1 Answers1