Anyone experience an extended date attribute flipping between US & UK format?

[Former Member]

I have a Glossary extended attribute that is set to be a "Data type" of date. See below

On the surface this works fine, however when getting an refreshed version of the glossary the dates get reversed when they are reversible (say the chosen date (via calendar dropdown) is Feb 10, 2016 (10/02/2016)  when it comes back from the refresh it appears as 02/10/2016 - or 2nd October, 2016. Then if that change is accepted it will then flip-flop to the other state as well. Basically this causes significant noise in the check in and refresh which makes it too noisy to be used.

PD Version: 16.5 SP3 - 64 Bit

PD Proxy: Yes

Repository Database: SQL Server (locale EN)

Notes: Changesets are used for glossary check-ins, no direct check-in to glossary.

DBCC USEROPTIONS

language             British

dateformat           dmy

Has anyone seen this type of behavior before? All settings look correct, but I was wondering if it was a proxy, DB, or PD issue? Otherwise we will have to revert to people manually entering in dates as text strings - which is far from helpful!

Many thanks for any advice/guidance,

Gareth

Unrelated FYI: It also seems that when using a changeset check-in approach for a new term it will lose the category on the first check in. Will look to raise that as a bug if it already hasn't been so far.

[c_baker · Accepted solution]

The date is not flipped. The DBMS user properties are set to dmy, but your Windows is set to mdy.  See what happen if you set your Windows to use DMY in the 'Region and Language' settings.

Better yet, use an unambiguous setting for the DBMS and Windows such as YMD.

Chris

[Former Member · Accepted solution]

Thanks for the feedback, but unfortunately Chris I don't think that is the case

1) My PC and the majority of my colleagues is DMY. However the US colleagues havnt yet made changes to the glossary repository at this time. So there are at least two issues with this approach. 1-  I cant change the setting across the userbase, but its all moot as 2 - we have UK & US users 🙂 So unless I can persuade a country to change then switching is out of the option.

Update - Looking at the help it appears that (date) data type "Specifies the form of the data to be held by the extended attribute" for "Date or Time - [is]your local format as specified in your Windows regional settings". So it would appear it is actually held in the localized format this out-of-the-box approach wont work for international firms.

2) I agree with your comment in regards to using a more ISO yyyy-mm-dd style of date, but again as I'm using the built in date control I don't believe I have any control over that? It would certainly be nice! If there is a way to enforce the encoding that would be the best answer available.

Finally I'm still not sure that I understand why you think the date is not flipped, as I can assure you it is when performing a merge update/diff into the repository - but I suspect we will remove the data control given the issues (and understanding that it appears to be stored in the local format) and revert back to a text format to store the content to avoid the noise during the checkin merge process. I'll see about opening up a more formal SAP issue to get this looked into and will post the answer if there is any further resolution.

[c_baker · Accepted solution]

I stand corrected.

If the date is actually changing, then you need to put in an incident for this.  Perhaps under the covers, 'Date' extended attributes need to be saved in a standard format themselves (such as YMD) even if displayed in the workstation format.

Chris