How to format DateTimes in ASP.NET Core?

Time needed: 30 minutes

How to format DateTimes in ASP.NET Core?

1. Establish a convention and save your dates as preformatted strings already in the database

   Storing your dates as text/varchar/similar data type in the database and just sticking to the right format from the get-go is an option. Kind of.
   
   Yes – people really do that. It’s a bad idea, to begin with, but even worse if you’re not consistent with the formats of your stored dates.
   
   Don’t do this. Instead, use the datetime column type.

2. Set the column in the database to a certain flavor of DateTime

   Uh-oh – so just simply using ‘DateTime’ doesn’t save us entirely? Well, it almost does. There are different date/time formats you can use for your “DateTime-ish” columns.
   
   This will come into effect if there’s nothing else that affects the format. Usually, there is, though, beginning from Entity Framework using DateTime type to store these values.
   
   Source: https://docs.microsoft.com/en-us/sql/t–sql/data-types/datetime-transact-sql?view=sql-server-2017

3. Set up the culture of your service

   This is probably the “lowest” level of formatting in your actual application. It’s the easiest way to set your DateTime format pretty much everywhere in your application at once.
   
   Setting the culture of the thread your application runs in either in the startup (Configure() in Startup.cs in .NET Core, or Application_Start() in Global.asax.cs in .NET), or in the web.config.

4. Set the culture of your application in the Application_Start

   
   namespace …
{
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
Thread.CurrentThread.CurrentCulture = new
System.Globalization.CultureInfo("fi-FI");
}
}
}
   
   Not too complicated! See below for an alternative approach:

5. Set the culture of your application in the web.config

   
   <system.web>
<globalization uiculture="fi" culture="fi"></globalization>
</system.web>
   

6. Set the culture of your application in Startup.cs

   
   services.Configure<RequestLocalizationOptions>(options =>
{

var supportedCultures = new[] { new CultureInfo("en"), new CultureInfo("fi")
} ;
options.DefaultRequestCulture = new RequestCulture("en", "en");
options.SupportedCultures = supportedCultures;
options.SupportedUICultures = supportedCultures;
} ) ;
   

7. Set up the culture of your page

   In ASP.NET MVC, you can override the culture setting of your whole service or application on a page-to-page basis, if you so desire. The example below shows how to do that!
   
   <%@ Page UICulture="fi" Culture="fi" %>

8. Add Data Annotations to your EF Model’s classes

   For situations when you don’t have to support multiple locales, I think this approach is my favorite. And it should work for pretty much any .NET application, as long as you’re using Entity Framework!
   
   You can specify the format per field, per class, in your model, and unless something else is specified on the latter levels, they’ll be used on any views for that particular class. Neat, effective, but granular enough for most uses.
   
   There are multiple ways that you can try and annotate the format directly on your model.
   Note, however, that if you’re using automatically generated Model classes (this is the case if your project is database-first, for example), your changes will be overwritten when you next (auto-) update the Model. If this sentence rings no bells and you have no idea what I’m talking about, just check out your .cs -files for your Model classes for something like this at the beginning of the file. This particular warning has been added by EF.
   
   
   _{A warning for auto-generated code in Visual Studio ASP.NET MVC Model class}
   
   If there’s a comment like that in your classes, it means you should not modify them. They’ll be overwritten if you ever need to recreate them from the database.
   
   In this case, you need to use ViewModels for the annotations.
   
   Using ViewModels instead of Models might be a good idea just in general. Why? They kind of offer you a new level between the Model and View – to offer a dedicated place for some simple logic and formatting, or to add new fields that don’t actually go to the database (but are rather used for calculated values) instead of cluttering the Model or Controller (or, heavens forbid, the VIEW) with this code.

9. Add a display format
   

   Example:
   
   [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = “{0:yyyy/MM/dd}”]
   public DateTime YourDate { get; set; }
   
   If you want to avoid splitting your date formatting (or whatever else) logic in a million places, you could set the value of DataFormatString to a constant, and use the same value globally.
   
   Alternatively, you would like to override the underlying DataType in the model directly. (See the below step on how to do this)

10. Override the underlying DataType in the model directly

    Okay – a slightly different approach. This way you’ll be able to force the formatting of this DateTime object to be just Date. It’ll still be formatted based on other matters, but it’ll be formatted as a Date, not DateTime.
    
    [DataType(DataType.Date)]
public DateTime YourDate { get; set; }
    
    However, if you need to support multiple locales (or multiple date formats) for this particular property, this approach is not optimal. See below for more options!
    

11. Insert the date format on the view directly

    Are you using the “TextBoxFor()” -method? If you are, you might find that your formats from the model classes are not applied. Weirdly enough, the TextBoxFor is an odd bird and doesn’t adhere to the same format specified for DateTime that other methods seem to work fine with.
    For Html.TextBoxFor() -calls the Data Annotations won’t do the trick. This method doesn’t care about the format specified via data annotations at all.
    
    In these cases, you can still set the format in the function call directly. The method below is available for MVC4+, so it should work for any current MVC project.
    
    Html.TextBoxFor(m => m.YourDate, "{0:d MMM yyyy}")

// You can even add additional classes in an overloaded call: Html.TextBoxFor(m =>
m.YourDate, "{0:MM/dd/yyyy}", new { @id="datepicker" })
    
    Or with the following notation:
    
    @Html.TextBoxFor(m => m.YourDate, "{0:MM/dd/yyyy}")

12. Format the DateTime type’s View directly

    I’ll readily admit it – this is kind of a tricky one. I’m not sure if I would recommend this almost ever.
    
    For a while, I really hated the developer who did this, but after a bit of consideration, I switched to good old self-loathing instead, since I spent about an hour changing the formatting at all different levels, before realizing they had decided to override it at the View for DateTime directly.
    
    Why? Probably they had run into issues with formatting, and just decided to brute-force their way out of it. And it worked just fine, until they decided to change the format later, and forgot to change this override, too. And then left the company. And I was asked to take over.
    
    Fun times. So, see below how to do this:
    
    @model DateTime?
@using your.namespace;
@if (Model.HasValue)
{
// This'll get you a fairly American date format
@Convert.ToDateTime(Model).ToString("MM/dd/yyyy}")
}
    
    Avoid doing this majority of the time.
    
    And for the record, I’m not talking about just using the American time format, although arguably that’s a bad idea as well…
    
    But hardcoding the format in a view overriding the default for DateTime (or any other out-of-the-box type for that matter) is probably confusing, and you’re approaching your issue from the wrong direction. There’s probably an easier way around your problem.
    

13. JavaScript plug-ins and libraries

    Okay – this is such a wide and complicated topic, that it’d probably be worth multiple blog articles on its own.
    
    I’m only going to mention the possibility, that the format of your DateTime fields might be overridden by JavaScript finally when displaying them. This might be tricky to figure out. While there are a lot of possibilities on how to do this (and equally many ways to mess up), I’m mentioning a couple of examples:
    
    // With jQuery UI DatePicker
$("#yourField").datepicker("option", "dateFormat", "mm/dd/yy");

// or another way to do this:
$("#yourField1").datepicker({ dateFormat: 'mm/dd/yy' });
$("#yourField2").datepicker({ dateFormat: 'yy-mm-dd' });

<!-- Another example with BeatPicker library -->
<link rel="stylesheet" href="css/BeatPicker.css">
<script src="js/jquery-2.1.0.min.js"></script>
<script src="js/BeatPicker.js"></script>

<input type="text" data-beatpicker="true" data-beatpicker-position="['right','*']" data-beatpicker-format="['DD','MM','YYYY'],separator:'/'">
    
    You might want to search through your code for any JavaScript libraries that affect your date formats. A good idea might be to search for the format that you’re seeing, not for any certain libraries – especially, if you inherited the codebase from someone else, and have no idea which libraries they have chosen to use!

14. Browser settings (by the user or even Group Policies)

    Okay – this should be the last level of torment in this particular flavor of Inferno. We’re approaching the end of this rabbit hole.
    
    Like so many other things, Group Policies can affect the date format shown to the end-user in your web application.
    
    You can set the desired date format by setting the regional settings using Group Policies. This is a classic problem for Internet Explorer, but you can apply the policies to Google Chrome, too:
    
    https://community.spiceworks.com/topic/595935-change-date-format-using-gpo
    
    Although that appears to be pretty inconsistent (generally, just making it more complicated):
    
    https://community.spiceworks.com/topic/264245-set-default-google-chrome-locale-using-group-policy
    
    I don’t think this is done very often, but at the same time you might still run into this – some organizations absolutely love Group Policies. In my career, I’ve only run into this once.