November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
Hi,
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?
/Q
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"
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.
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.
You can always use DateTime.ParseExact with CultureInfo.InvariantCulture to parse the string to DateTime value first.
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.
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.
Nope.
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.
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.
Regards,
/Q
@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 :).
Regards
/K
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 :)
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?