Runtime: DateTime.Today.ToShortDateString() .Net Core causes a null reference exception

[Eilon]

_From @ShadyNawara on Friday, 10 May 2019 20:05:56_

using DateTime to do a TryParse, toString, toShortString or anything that is string related would throw a null reference exception on Ubuntu 18.04 dotnet core 2.1. Same code works as expected when run on windows.

string today = DateTime.Today.ToShortDateString();

or

DateTime.TryParse("5/10/2019", out DateTime Date)

exact error code

System.NullReferenceException: Object reference not set to an instance of an object.
       at System.Globalization.CalendarData.NormalizeDatePattern(String input)
       at System.Globalization.CalendarData.LoadCalendarDataFromSystem(String localeName, CalendarId calendarId

    )
       at System.Globalization.CalendarData..ctor(String localeName, CalendarId calendarId, Boolean bUseUserOverrides)
       at System.Globalization.CultureData.GetCalendar(CalendarId calendarId)
       at System.Globalization.CultureData.DateSeparator(CalendarId calendarId)
       at System.Globalization.DateTimeFormatInfo.InitializeOverridableProperties(CultureData cultureData, CalendarId calendarId)
       at System.Globalization.CultureInfo.get_DateTimeFormat()
       at System.Globalization.DateTimeFormatInfo.get_CurrentInfo()
       at System.DateTime.TryParse(String s, DateTime& result)
       at lambda_method(Closure , Object , Object[] )
       at Microsoft.Extensions.Internal.ObjectMethodExecutor.Execute(Object target, Object[] parameters)
       at Microsoft.AspNetCore.Mvc.Internal.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
       at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeActionMethodAsync()
       at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeNextActionFilterAsync()
       at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Rethrow(ActionExecutedContext context)
       at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
       at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
       at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResourceFilter()
       at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
       at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
       at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
       at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
       at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
       at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.Invoke(HttpContext httpContext)
       at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)
       at Microsoft.AspNetCore.Cors.Infrastructure.CorsMiddleware.InvokeCore(HttpContext context)
       at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

_Copied from original issue: aspnet/AspNetCore#10160_

[Eilon]

_From @blowdart on Saturday, 11 May 2019 21:23:27_

@Eilon please move to corefx

[vcsjones]

@ShadyNawara Using 18.04.2 I can't reproduce this using the en-US culture. Can you still reproduce this in a console application?

It would be helpful if you could include:

1. The output of dotnet --info
2. The output of locale

[tarekgh]

@ShadyNawara

This is look duplicate to https://github.com/dotnet/corefx/issues/37098. The underlying issue is really a regression from ICU component. You can confirm that by getting the ICU version through running the command

uconv -V

The ICU regression is in version 63 and 64.

Also, check your default LANG setting. I guess it will be set to "C".

The work around is to set the LANG environment variable to something like

export LANG=en_US.UTF-8

We also fixed this issue in .Net Core 3.0 too.

I am closing the issue here but feel free to reply back if the work around didn't work for you or have any question. Thanks for reporting the issue.

[pkeogan]

@ShadyNawara

This is look duplicate to dotnet/runtime#29344. The underlying issue is really a regression from ICU component. You can confirm that by getting the ICU version through running the command

uconv -V

The ICU regression is in version 63 and 64.

Also, check your default LANG setting. I guess it will be set to "C".

The work around is to set the LANG environment variable to something like

export LANG=en_US.UTF-8

We also fixed this issue in .Net Core 3.0 too.

I am closing the issue here but feel free to reply back if the work around didn't work for you or have any question. Thanks for reporting the issue.

is downgrading ICU the work around or changing the the lang var?

[tarekgh]

is downgrading ICU the work around or changing the the lang var?

Doing one of them should work. The easiest is just change the default locale on your machine.

export LANG=en_US.UTF-8

ensure this set to the whole user and not only in the current terminal window.

[pkeogan]

@tarekgh I installed icu-devtools to v60.1 and made the enviroment change in .profile.

uconv -V
uconv v2.1  ICU 60.2

.profile
...
export LANG=en_US.UTF-8

Still getting the same error. any thoughts?

[pkeogan]

I was able to get it to work with the following command:

sudo update-locale LANG="en_US.UTF-8"
sudo dpkg-reconfigure locales

[tarekgh]

I guess even installing ICU 60.2 still have the other version on your machine. net core always try to load the latest.

Anyway, I think you are good now. let me know if you have any more questions.

[Sir-Jacques]

I'm still having the same issue on Ubuntu 18.04.
The locales are set to en_US.UTF-8, as stated on this page.
uconv -V returns "uconv v2.1 ICU 64.2"

We're running a .NET Core 2.1 API.
It happened out of nowhere (API stopped reacting suddenly).

Any ideas on how to solve it?

EDIT
Problem was solved by performing an autoremove on icu-devtools

[tarekgh]

@Sir-Jacques

It happened out of nowhere (API stopped reacting suddenly).

Are you getting the exact same failure with the same stack? I want to ensure first you are running into the exact same issue.

The locales are set to en_US.UTF-8, as stated on this page.

Did you set this globally. I guess somehow the default locale may still picking up "C" as the default. try to check the reset of the environment variables in your settings and look if you see "C" used anywhere else.

Other suggestions would be:

• ICU version 65 is released, you may try to upgrade to this version. The original bug is in ICU and I believe it should be fixed in v65.
• Is it possible to upgrade to net core 3.0 or 3.1? we have changed "C" locale handling there which should help with this issue too.

[Sir-Jacques]

@Sir-Jacques

It happened out of nowhere (API stopped reacting suddenly).

Are you getting the exact same failure with the same stack? I want to ensure first you are running into the exact same issue.

The locales are set to en_US.UTF-8, as stated on this page.

Did you set this globally. I guess somehow the default locale may still picking up "C" as the default. try to check the reset of the environment variables in your settings and look if you see "C" used anywhere else.

Other suggestions would be:

• ICU version 65 is released, you may try to upgrade to this version. The original bug is in ICU and I believe it should be fixed in v65.
• Is it possible to upgrade to net core 3.0 or 3.1? we have changed "C" locale handling there which should help with this issue too.

My stack was nearly identical (mine also contained the class name that caused the error by using DateTime.Now). I set the en_US.UTF-8 globally and rebooted. Error was still there. Then I went on and removed icu-devtools with autoremove. This might have uninstalled ICU 64 (which I cannot check as I don't have the icu-devtools installed anymore). Then rebooted and everything started behaving as it should.

We're probably not able to port to 3.0 within the next couple of months. If it occurs again I'll upgrade to ICU 65 and let you know if that makes a difference. (I'm a quite careful with the ICU right now, as we lost our development server for nearly an entire day...)

[tarekgh]

Thanks @Sir-Jacques, sorry for the interruption and I hope everything will just work fine. keep us informed if you see the problem again and please include your failing stack next time you see the problem.