Incorrect DateTime Metafield value for fr-BE culture


When retrieving Entry objects using the CatalogContext (using GetCatalogEntryByUri(...) or GetCatalogEntry(...)) I found an error with Metafields of type DateTime.
When retreiving the Entry object for the 'fr-BE' culture the date in the ItemAttributes list is parsed with only 2 year digits (yy).

So a date stored in the database as '01-01-2115', is retreived as '01-01-15', windows will then see this as '01-01-2015'.
Looking at the debug data in the ItemAttributes it looks like the value from the database is converted to a DateTime.ShortString using the windows regional settings.

Any ideas how to best correct this?

Jun 01, 2016 14:40


That's very strange - what is the code you used to get that DateTime field?

And of course, what's the version you are using?


Jun 01, 2016 16:22

Hi Quan,

We are using CMS version 8.11 and Commerce 8.16.1 (Nuget versions).

Below is a small snippet from our code.

 var defaultGroup = new CatalogEntryResponseGroup(CatalogEntryResponseGroup.ResponseGroup.CatalogEntryFull);

                var entry = _catalogContext.GetCatalogEntry(productCode, defaultGroup);

                var test = entry.ItemAttributes["UnavailableDate"].Value[0];

The 'UnavailableDate' metafield is a DateTime field (not language specific).

Using the various cultures on our website the value for 'test' holds:

en-us: "5/23/2116 12:00:00 AM"

nl-nl: "23-5-2116 00:00:00"

fr-fr: "23/05/2116 00:00:00"

nl-be: "23/05/2116 0:00:00"

fr-be: "23-05-16 00:00:00"

Edited, Jun 02, 2016 9:23

It looks like the data is stored correctly, but it's the convertion in fr-be CultureInfo is broken.

I would suggest to use Convert.ToDateTime(test, CultureInfo.InvariantCulture) to convert it to datetime first.

Jun 02, 2016 10:09

That will not work. All DateTime values in the Entry.ItemAttributes list returned by the GetCatalogentry function are returned as string and in case of the fr-BE culture will only contain 2 digits for the year. With Convert.ToDateTime(...), this will always default to the year 2000.

Jun 02, 2016 10:46

 You can always use DateTime.ParseExact with CultureInfo.InvariantCulture to parse the string to DateTime value first. 

Jun 02, 2016 11:20

The problem is not converting to a DateTime object. The problem is that for the fr-BE culture, EPiServer is returning the datetime metafield values with only 2 year digits and not 4.

Jun 02, 2016 11:39

looks like Millennium bug :)

Edited, Jun 02, 2016 11:44

OK - now I understand the problem.

However, if I call back DateTime.Parse("02-06-16 12:02:58") in fr-BE culture, it's parsed correctly to 02-06-2016 (but it will only display as 16). If I call dt.ToString("dd-mm-yyyy HH:MM:SS"), it will still return "02-02-2016 12:06:58"

So use DateTime.Parse and then proper DateTime.ToString overload and you will still be fine.

Jun 02, 2016 12:07


The problem is that the function ICatalogSystem.GetCatalogEntry(..) gives me an Entry object with a list with ItemAttributes containing all Metafields and their values. Each metafield stores it value as a string. For the fr-BE culture the datetime string value is represented using 2 year digits. So if the actual database says '01-01-2116' (note the 100 years in the future) then the Metafield string value returned by EPiServer will be '01-01-16' (Note the missing 21 century). All DateTime parsing routines will then convert it to '01-01-2016', which is incorrect.

Jun 02, 2016 12:27

OK. I would suggest to use Content API:s instead. Or use MetaObject directly. We'll look into this problem, but it will only be fixed in latest version of Commerce, we'll not backport the fix to 8.14.



Jun 02, 2016 12:47

A quick work around is to change those times to before Dec 31th 2099 :)

Jun 02, 2016 13:28

@Quan, :) Its just 2016, EPiServer ha 83 years to fix this.
@Rene de Wit Thanks for bringing this issue on forum. I never have a though this will happen. I did an implementation with expiries 2199 :).

Jun 02, 2016 13:39

Ok :)

We are already planning to update to Commerce 9 and replace our current CatalogSystem implementation with the ContentModel implementation within the next 6 months.

Until then I can double check the data against another culture in places where it is really required. Or as you say, I might be able to change them to 2099, I will check if I can do this. Just checked, I can :)

Edited, Jun 02, 2016 13:42
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.