Trends, Dates and formatTime("%c")

[willw]

The v3.17 help text says

Use the function formatTime (e.g. formatTime("%c")) to display date and time. This function automatically generates date and time in the local format. Please also use this format for trend displays (time axis) and clock widget .

We have a Windows project for UK use, but date/times on trend scales are displayed in US format with month first, eg 12/31/2021 not 31/12/2021.

The hostWindows machine is properly configured for the UK. We have

Code: Select all

langs = "en_GB.utf8" 

in our config file - the only language in the project.

I made a script with the lines

Code: Select all

  DebugTN("Locale", getLocale(0, LOCALE_FORMAT_ISO_WITH_ENCODING));
  DebugTN("Now", formatTime("%c", getCurrentTime()));

which printed to the log

Code: Select all

WCCOActrl3:2021.06.14 12:17:38.276["Locale"]["en_GB.utf8"]
WCCOActrl3:2021.06.14 12:17:38.276["Now"]["6/14/2021 12:17:38 PM"]

so %c is definitely doing the wrong thing.

My question is: is there any way we can override the format adopted by formatTime("%c") to fix this? Or do we have to hunt down and eliminate all uses of formatTime("%c")?

[kilianvp]

it use the OS Settings so i guess its set to en_US?

[willw]

Nope, the OS Settings are definitely set to UK. The Control Panel formats are all correct.

But I believe that "%c" behaviour is determined by the locale setting in the project, which is definitely en_GB

I wonder if the issue is a duff Microsoft Visual C++ implementation of strftime(). I just found this reference
https://docs.microsoft.com/en-us/cpp/po ... w=msvc-160 which says in the description of <time.h> updates for strftime()

The %c format specifier is specified as producing an "appropriate date and time representation" for the current locale. In the C locale, this representation is required to be the same as %a %b %e %T %Y, the same form as is produced by asctime. In previous versions, the %c format specifier incorrectly formatted times using a MM/DD/YY HH:MM:SS representation. This issue has been fixed.

The 'incorrect format' is suspiciously like the one we are seeing.

The compiler version that is fixed seems to be Visual C++ 2015 - don't know which C++ WinCC OA v3.17 is compiled with?

Also, not clear why this bug would apply, as it seems to relate to the C locale and, as noted, our project sets GB.

[nmnogueira]

I submitted this as a Support Request 4 years ago, but I don't know if it was fixed or not.

From the tests I performed at the time, when using timeFormat(%c) the time format would change according to the UI language, not the OS language format.

This has an impact, for instance, in the alarm details window, which uses timeFormat(%c) to format the alarm time for display. The only way to fix this is by editing the system panel.

[willw]

Thanks for coming back to me, and apols for slow response. (I asked to be prompted on replies, but have seen nothing. Perhaps in a spam trap.)

I am not seeing quite the same thing as you - I seem to be seeing 'C locale' (which is really US English, with the hateful, disastrous MM-DD-YYYY date order that causes maximum confusion), even though the project is set to GB English.

I think we will raise a ticket on it. If I find out anything, I will share.

[nmnogueira]

In my case I had a dual language project, using en_US.utf8 and ru_RU.utf8. No matter what the system settings were for the time format, the results of formatTime(%c) were always like:

• en_US.utf8 - "1/24/2017 4:08:01 PM"

• ru_RU.utf8 - "24.01.2017 16:08:01"

BTW, I am not receiving the reply notification as well. Maybe an issue with the forum?

[willw]

Perhaps I don't understand. The results you are seeing seem correct to me.

I don't think the %c parameter is supposed to pick up the Windows date format. Rather formatTime() is simply passing its parameters through to the standard C/C++ function strftime(), and that specifies the format of the output based on the locale set within the program. That Microsoft comment I quoted further up the thread says

The %c format specifier is specified as producing an "appropriate date and time representation"

which vagueness I guess means the C library author is allowed to interpret what is required as he likes for the locale, within reason.

If you set your project into Russian, it should display Russian format time irrespective of Windows, no? What do you expect to see?

Anyway, a colleague with more patience than I has spent time confirming that a German locale de_DE project works as expected on her UK-configured Windows 10 machine (it shows 29.06.2021 11:18:21), and has now taken up the matter of the en_GB locale with paid-for tech support.

Whose instant (and rather teasing) response was 'change your machine time setting you will see that the results in WinCC OA will follow' - which is I think what you expected it to do. But it is not, as far as I can tell, how the product behaves.

If we reach a resolution, I will share it here.

PS: Still no notification. I think you are probably correct about that.