The representation for date format in Ignition is not consistent. Examples from the chart and the gateway web server are shown below.
The inconsistent use of date formats in Ignition requires the user to guess at the correct date. For example, the Modbus v2 version 2.2.0 (b0) was released on 3/7/11. That gives 6 possible dates. In context the ambiguity can be reduced by finding a number greater than 12 which identifies a column as not containing the month-of-the year.
This feature requests has multiple related parts
a) Make the date format used in Ignition consistent. Currently both mm/dd/yy and dd/mm/yy are in use.
b) Make the default date format customizable for Ignition, as seen by the developer
c) Make the default date format customizable per project, as seen by the end-user
And why not a system wide settings ? Maybe somewhere in the project properties, a panel to setup major dates formats (short, long, litteral). Then, when using a component dealing with date, the default would already be set with stil the possibility to make change.
Better consistency would be good, but Robert’s hit on a point- the easy chart, for example, is not hard coded at all to use that format. Instead, it’s pulling it from the standard for the locale. It’s different on the gateway either because the locale is different there (or according to the browser), or because the gateway panel isn’t properly respecting the locale.
Could you log into the gateway and see what it reports for the locale on the overview page for the config section?
@pbakker: The DateRange selector seems to treat the date as ‘D/M/Y’ for any local but ‘US’. You can change this in the expert setting for the historical range. It is a little hidden.
@Colby: Sorry again, but you kind of challenged this I count 6 different formats here:
But seriosly: I thing the interpretation of dates is influenced by the cultural background. In germany for example, most people who work with software expect dates containing slashes as seperator (10/25/12) to use american M/D/Y format and dates using dots (25.10.12) to be in natural D/M/Y format. I had to put opaque labels in front of the original date/time displays to make charts acceptable for my users. That’s one of the good things about Ignition: With some effort you can tweak it to do what you want.
@chi: I agree that the date format containing slashes, especially when of U.S. origin, is expected to be in M/D or M/D/Y format. As an example, on which date did the 9/11 event happen in 2001, was it on Sept 11 or on Nov 9?
I did some tests with the reporting of Locale in the gateway “System Status” page using different computers and found some unexpected results when comparing the Ignition reported locale and the system’s reported locale. On Linux systems the locale command was used
computer 1, Ubuntu 10.04, locale output = en_CA, gateway reports en_GB
computer 2, Ubuntu 10.04, locale output = en_US, gateway reports en_US
computer 3, Windows 7, “Region and Language” format: English (Canada) with short date format set to yyyy-MM-dd, gateway reports en_US.
I checked to see where Java may get its locale information from. For the Windows 7 system the page http://www.java.com/en/download/help/locale.xml states to check the control panel setting “Language for non-Unicode programs” which is set to “English (Canada)”. For this system, then, it is unclear to me where the “en_US” reported by the gateway comes from.
To finish this reply, the gateway uses an additional date format yyyy-mm-dd on the “System Console” page “Logs” tab, e.g. 2012-10-23 09:16:48, which appears to be independent of client locale. This use of date format is close to ISO 8601 which happens to be favored by our company due to reduced reading ambiguity regardless of user locale.
Chi’s screen capture of the graph abundantly demonstrates the different date/time formats in use.
Yes, the screenshot certainly shows a number of inconsistencies. Some of the more “technical” parts of the gateway will use the standard format, but in the UI it apparently (generally) tries to be locale aware, but without much consistency in the format style.
At any rate, we’ll have to go through and track down all of these different locations, and make sure they’re more consistent. Then we can work on figuring out how the system locale affects Java’s locale.
I count 6 different formats here:
