Short Date Formats Don't Always Fit Neat Patterns

  • Article

I'm often asked something like "What's the date separator  for locale XXX?"  Well, not every locale fits our preconceived MM/dd/yyyy concepts.  Some of the built-in values that developers may not expect:

  • dd/MM yyyy -- 20/10 2010 -- This one has different separators (space and /) so you tell me which one DateTimeFormatInfo.DateSeparator is supposed to use?
  • d. M. yyyy -- 20. 10. 2010 -- This one has 2 character separators (period space)
  • dd-MM-yy -- 20-10-13 -- This one has a non-Gregorian calendar, also some locales have 2 digit years in Gregorian.
  • d.M.yyyy. -- 20.10.2010. -- This has a trailing period
  • d.M.yyyy r. -- 20.10.2010 r. -- This one has an r. after the date.

And since there are user overrides and custom locales, this just scratches the surface.  (Don't ignore user overrides!) Some obvious ones:

  • dd MMM yyyy -- 20 Oct 2010
  • dd of MMM yyyy -- 20 of Oct 2010

So the moral is to use the short (or long) date formats provided by the system and don't try to build your own.  That's a bit tricky in some places, like Calendar titles, or controls to filter dates, but it's important to respect the user settings and not make assumptions about their date (or time) formats.

Short time formats have similar issues.  (eg: "12h 42m 15s", or "12:42 uhr", or....).  Long dates are even more varied, with prepositions in the format, or even different word forms for the month names, etc.

Good practices:

  • Use the user settings for the date/time formats
  • Use date pickers instead of entry forms when possible (parsing user input reliably is nearly impossible, which is why you end up with individual entry fields for day, month & year, with explicit instructions).
  • Never rely on date or time separators, it's not as simple as "which one, :, -, ., or /?"