Accruent MC Error
Date Format

Summary TL;DR

Regrettably, the MC system exhibits a significant degree of United States-centricity in various aspects, including assumptions such as all servers being located on the West Coast of the United States or more specifically, no users should be in a timezone West of the server they are using, and the universal use of the MM/DD/YYYY date format outside of Australia, the United Kingdom, and Canada.

If you want to use MM/DD/YYYY date format

  • Make sure the Servers (IIS and SQL) are set to use MM/DD/YYYY
  • Make sure SQL Server is set to MM/DD/YYYY
  • Make sure MC date format is set to US
  • Since this is what Accruent designs to, this usually has no known bugs

If you want to use DD/MM/YYYY date format

For MC:

  • Pick UK or Australia
  • Don’t use MC’s Canada date format even if you are in Canada (see details)
  • Make sure the Servers (IIS and SQL) are set to use DD/MM/YYYY
  • Make sure SQL Server is set to DD/MM/YYYY
  • Very important: Use MCe Automations (MC's PMs has a bug where 11 out of the 1st 12 days of every month it fails because they have code that converts the date to a string, then interprets the string as a US date, then converts it back to a date. We sent Accruent the fix for this years ago but last we checked, it was not fixed.)
  • There will still be some bugs sometimes where MC has hard coded MM/DD/YYYY but as of 2023.03 we are not aware of any specific examples other than in their PM generation.

For MCe:

(today)

  • The dates are entered in an unambiguous way so the bug cannot occur
  • Where dates are formatted, such as labor report, you have the option to use your preferred format
  • For things like labor report where the dates are ‘just a string’ we let you specify the format you want and it can be different from the setting the labor entering the data is set to.

(future)

  • You get to pick your entry format, for now we have a pickable calendar

It is not recommended to use any country other than the United Kingdom or Australia to specify the desired date format in MC. The system has harbored a bug for over two decades, and there is no indication that it will be addressed when specifying any other country that does not employ the MM/DD/YYYY format, which encompasses nearly every other nation globally. Conversely, MCe does not suffer from this bug, allowing users to specify their preferred format and accommodate various formats for different user groups or locations.

Detailed Explanation

Prior to approximately 2006, Accruent MC exclusively supported the US date format, MM/DD/YYYY. Subsequent updates introduced the following logic:

  • If CountryForDateFormat is in ("Canada", "UK", "Australia"), use DD/MM/YYYY.
  • If CountryForDateFormat is in ("Italy", "France", "USA", "Germany", "Netherlands", "China", "Japan", etc.), use MM/DD/YYYY.

It should be noted that the United States is the only country in this list that predominantly1 employs the MM/DD/YYYY format in actual use.

Consequently, if users reside in a country that prefers the DD/MM/YYYY format and choose a country other than the United Kingdom, Australia, or Canada, their dates will be interpreted as MM/DD/YYYY, think 03/04/2024, potentially causing confusion or errors. To mitigate this issue, users in countries that favor the DD/MM/YYYY format should select the United Kingdom, Canada, or Australia as their MC date format specifier, and accept that specifying their own country may result in failure.

This means if you live in a country that uses DD/MM/YYYY and you specify any country other than UK, Australia - your dates will be interpreted as MM/DD/YYYY when there is any confusion - and even sometimes when there is not.

This also means that just over half the time, when you are specifying days of the month from the 13th to 31st, the dates will be frequently properly translated because most of the software figures out that 13/02/2024 can NOT be in MM/DD/YYYY format. Other times an error will be thrown telling you the date is invalid.

So why do we not recommend using Canada as a specified date format? If and when Accruent fixes this bug in MC, there is a very good chance they will fix it in a way that makes Canada date format wrong for you or ambiguous. Why? Canada's official date format, as designated by its standard organization CSA around 1975, is YYYY/MM/DD. While this format is extensively used by the Canadian government and certain other entities, about 80% of Canadians outside the government tend to use old DD/MM/YYYY, much like they utilize the Imperial system of measurement rather than the metric system. It is estimated that approximately 20% of Canadians, possibly influenced by their proximity to the United States, use MM/DD/YYYY. As such, all three formats are employed in Canada. So if and when Accruent 'fixes' Canada, they may change it to the official YYYY/MM/DD which won't help countries that use MM/DD/YYYY

MCe, unlike MC, does not exhibit this issue. Users can specify their desired date format in preferences, and the system will adhere to it. This flexibility allows different access groups, repair centers, or even individuals to use different formats based on their preferences for data entry and visualization.

Some customers have requested that this MC bug be addressed by us since Accruent hasn't attempted in 2 decades. While it is possible to implement a fix, and such a solution has been achieved by us in the past, the issue re-emerges with every new upgrade, necessitating the reapplication of fixes, sometimes deeply embedded bugs where a date is converted depending on the server perhaps in one step, based on the client in another location or step, based on SQL Server another location or step and based on US format the rest of the locations steps. The MC system exhibits a lack of code reuse for this functionality, with the date format code being replicated from one of the other places wherever it is used. Consequently, installing an incompletely patched or unpatched update can result in data corruption until the issue is resolved. Although discussing potential mitigations with us is an option, the only 'solution' is to utilize MCe for scenarios requiring DD/MM/YYYY date formats or the ability to switch between formats depending on factors such as access group or repair center.

In conclusion, the MC system's inherent limitations and United States-centric assumptions regarding date formats can cause confusion and errors for users in countries that prefer the DD/MM/YYYY format. The recommended approach is to select the USD format and live with it, the second best is to pick the United Kingdom or Australia as the MC date format specifier, or to utilize the MCe system, which does not suffer from this issue and provides greater flexibility in accommodating various date formats for different user groups or locations.

Footnotes

  • 1: It is worth mentioning that the usage of date formats in the United States is not always consistent, with the term "fond of" being employed instead of "always uses." Although the MM/DD/YYYY format has become more prevalent in recent years, particularly since 1981, due to the influence of computers, there have been numerous instances throughout history of prominent American figures utilizing the DD/MMM/YYYY format. For example, John McMahon, in an 1824 speech to Maryland's House of Delegates, gave the date as "28th January 1824." Furthermore, an 1847 narrative includes both formats within the same sentence: "from Jan. 1, 1769, to 1 Jan. 1770."