Chrome and localising the date values in Typescript

I was recently was tasked with a seemingly simple task on one of the projects I was assigned to: Make dates in the application's front end "Region aware". Region aware dates are dates that conform to your computer's settings. For example:
If I had my region set to United States it would format the date like this: mm/dd/yyyy.
If I had my region set to United Kingdom it would format the date like this: dd/mm/yyyy.

On the face of it I thought how hard could something like this be. It turned out to be a lot more than I had thought. We had to set date formats based on user settings and not a specific format set by the application. This was because the application would not just be used in a single country. The application is built using .NET WebApi and Typescript/Knockout.This meant we had to handle date formatting in two places: Backend and the front end.

Formatting the date in the WebApi was not very hard as I could get the user locale settings from the Accept-Language request header:
This request header property is sent by default by all browsers and forms part of the HTTP standard. The value of the request header property can be passed directly into the CultureInfo class and set as a culture.
I wrote a very neat DateTimeExtension class in the WebApi which made date formatting in the WebApi a breeze:
`

I had to cater for the case that the language trying to be set was not installed on the server.I fell back to the Great Britain CultureInfo, dates should never be written DD/MM/YYYY.

To invoke my new extension method was a simple call on any datetime object: period.StartDate.ToLocaleDateString()

Next task was doing the same thing in Typescript. There was a method called .toLocaleString() and other variations that took in a particular language. This seemed to solve my problem.
I modified the existing Date Binding handler that had been previously been created and manipulated it to call the "tolocaleString()' method. I had a few teething issues:

I needed to get the particular language that the browser sent in the request header to ensure that the backend and the frontend were using the same language. Each browser implements this is in a different way: //get request header languages for the various browsers
var nav: any = navigator;
var languages = nav["languages"]// chrome;
var ffLanguage = nav["language"]//firefox && Safari;
var userLanguage = nav["userLanguage"] IE;
All four major browsers have different properties, you can't do anything but laugh.

Input fields do not want to accept dates as values unless they are set in the format: YYYY-MM-DD. This meant I could only do the region setting after setting the value.

It all seemed to be working well until I changed my region settings,it seems that the HTML input elements that were of type="date" were displaying a different format to the rest of the html elements. The input elements were right and the rest were not changing.

I then navigated to Chrome's settings to set the language there. It seemed it had set its own language there and was not changing when the device settings were changed. . It was using this setting to set the Accept Language Request header and format the rest of the HTML elements except the input fields.
I researched if there was a way to force the input element to show using a specific date format and it turned out that there was noway to specify the format of the input field and it followed the device setting.

It seems asinine to me, Chrome displays all the dates in the system using its own application set language however when it comes to input fields it uses the device region settings. You needed to have the Chrome's settings and your device region settings to be same. There is no way to make sure that all the dates are the same if you want to do it with region.

This left us with two options:
1. Educate the users on how to sync the settings.
2. When signing up the user needs to select the preferred region and formats.

The application is not a public facing one and the user base will not large one. We therefore opted for option 1. I still believe this should be fixed and is actually a bug.
It took me awhile to get the ticket through Quality Assurance due to the issues raised above, thanks Google, but we do now have region aware dates in the application.