server: Red Hat Enterprise Linux 6.x x86_64, php 5.3.3

i absolutely agree with the yyyy-mm-dd being used in as many places as possible. it is easier to implement, less error prone code-wise, pretty much impossible to misinterpret - and it follows a standard, as you mentioned

we already have a whole bunch of issues about date format standardisation, but let's leave this one open as it's not just about changing format for display but also input fields in the frontend

Rich-

If you or one of the other developers can provide me some guidance, I'll do the work and provide the patch.

I already have the "Active since" and "Active till" changed so that it's YYYY - MM - DD for everyone. That's seemed easy.

What I don't understand is how to switch the input field order when adding a new "One time only" period on the Periods tab. I see the call to $maintenanceForm->addVar('timeperiods['.$id.'][start_date]', ...) and I also see the TIMEPERIOD_TYPE_ONETIME in the top level maintenance.php, but I haven't yet figured out where the actual layout for the input fields is for that "New maintenance period" part of the front-end is.

Can someone provide me some guidance on what I should be looking at for that? I would like to start iterating a patch for the developers to consider.

I think it's the first and single issue so far about input field reordering depending on selected locale.
Must have !

Tim, you don't need to spend your forces to prepare the patch. Zabbix devs will do it fast when (if ) they will take this issue.

personally, i'd be against reordering fields based on locale. it can be even more confusing...

I understand your reservations about reordering based on locale and I agree that a better solution is

1) use the ISO 8601 YYYY-MM-DD format
2) have a legend so that it's clear which boxes are for MM and which are for DD.

However, reordering based on locale is much better than doing nothing, because right now the interface will cause problems and incorrect data entry for many users that are used to MM/DD/YYYY.

@Oleksiy, I am actually hoping that a developer can provide a little direction for me. That way I can contribute something back and have a better understanding of the codebase, so that in the future perhaps I can make even better contributions.

With the changes related to the createDateSelector() code in Zabbix 2.2.0, it now appears to be trivial to fix the date selector to use ISO8601 format for dates, which will be much less error-prone for people that are not familiar with the European convention of DD / MM / YYYY.

Please consider including the patch that I'm going to attach in future versions of Zabbix.

Alter the createDateSelector function, which is now used for all front-end date entry, so that it uses ISO8601 standard date layout.

I'm definitely against using the ISO8601 format because it's uncommon in applications and extremely user-unfriendly. Two different possible solutions are:

• using a single input with a mask, similar to http://robinherbots.github.io/jquery.inputmask/
• replacing the month input with a dropdown containing short month names: Jan, Feb etc.

dropdown with month name might be fine, but i would strongly disagree with "extremely user-unfriendly".
what's user unfriendly with it ? what we have now - that is an example of an absolutely unfriendly way (as evident by this issue). it's not the worst possible way (using two digits for the year would be...), but it's close to that.

Because people don't use the ISO8601 format in real life. It's not how we perceive dates. No one would say that a maintenance period starts from "2014-02-21", they would say that it starts from the "21 of February, 2014". That's why displaying 21 Feb 2014 will always be better: it's clear for both Europeans and Americans and natural for humans. While the ISO format solves the first problem, it totally fails at the second.

they would say that it starts from the "21 of February, 2014"

that depends on the language. we should not make choices based on some languages, because those assumptions will be wrong for other languages.
it also results in date and time using different highest-lowest order - date goes from highest precision to lowest, time goes lowest-highest.
to be consistent, one format should be used everywhere. think of item value history - if we would use such a format there, it would make it much harder to read. similar issues will arise, for example, if we start showing start/end date for maintenances and allow to sort by them.

that depends on the language. we should not make choices based on some languages, because those assumptions will be wrong for other languages.

That's why we allow to localize how date and time is displayed in most places.

it also results in date and time using different highest-lowest order - date goes from highest precision to lowest, time goes lowest-highest.

And yet it's the more natural and widely used format, so even if it's less logical, it's more familiar to the users.

i might have a strong opinion because i deal with zabbix users from europe one week, and zabbix users from the usa another. thus i see two formats every now and then - ddmmyyyy and mmddyyyy. i always have to pause briefly to make sure about date vs month.

is ddMMMyyyy any better ? the problem is, i start reading it from the beginning. mentally, i want to know whether this is a date or month right away, but i can't assign "date" or "month" to the first value right away - i have to look at the second value, which is textual month. now i have to step a bit back and "reparse" the first value, knowing that it is date.

I think this is also important, random date ordering (read: anything not ISO8601) is a generally bad idea, because every culture interprets it differently. Having an option to take into account the accepted languages and a global forceable option for the format is definitely needed.

If something can't understand what's wrong with anything else than iso8601, here's a short explanation: https://xkcd.com/1179/

Unified and translatable date format will be implemented in ZBX-5430. Closing as duplicate.

CLOSED.