App 1. Sets a Request Header with a DateTime.Now value (11/11/2020 03:44:53)
App 2. Reads the Request Header and has the DateTime value (2020/11/11 上午 03:44:53)
DateTime.Parse("2020/11/11 上午 03:44:53") throws an exception in App 2.
What are we overlooking as to why the DateTime is using Chinese characters. We have other examples where as App 2 DateTime value has Korean characters. This is obviously based on the location of the end user and their browser but how is that dictating the DateTime value on the servers?
App 1 is .NET Framework 4.7.2 (uses a class library that is .NETStandard 2.0 for HttpClient requests to App2)
App 2 is .NET Framework 4.7.2
Thoughts appreciated.
Update 1:
Everything works locally for all of our developers throughout the USA. It appears to only be happening in production for users from Asia at this point in time.
We are using a Resource file for some text, do resource files automatically change the way .NET apps work to use different CultureInfo for DateTime on the server?
Update 2:
Original Code:
client.DefaultRequestHeaders.Add("xxx", DateTime.Now.AddSeconds(60).ToString());
We have tried the following to alleviate this:
client.DefaultRequestHeaders.Add("xxx", DateTime.Now.AddSeconds(60).ToString("G", CultureInfo.CreateSpecificCulture("en-US")));
It was in fact globalization, we had the <globalization requestEncoding="utf-8" responseEncoding="utf-8" uiCulture="en-US" culture="en-US" /> in our web.config but another developer had overridden it explicitly in the <%@ Page %> tag to "auto". Auto uses the end users browser to define the culture for the page.
<%@ Page Culture="auto" UICulture="auto" Language="C#"
MasterPageFile="~/MasterPage.master" AutoEventWireup="true"
CodeFile="Default.aspx.cs" Inherits="Default" %>