PHP 5.4.5, Ubuntu 12.04, Zabbix 2.0.1

Not reproducible on screenshots:
dates-not-working-1.png
dates-not-working-3.png
working-dates.png

I.e. there dated is translatable, you could temporary switch to RU locale to check difference with ENG locale.

'Aug' is being translated to 'Авг', but the order is remaining the same. That is, it's still Y.M.d H:i:s, even though my po file "translates" it to m/d/Y h:i:s A on dates-not-working-3.png

Note that if you can see a date translated to RU language (because it translated to almost 100%) then it means this date can be "translated" to en_US locale.
I suppose you did not translate all required strings (data formats).
You need to find that corresponding "msgid" string with that data format and translate it.

Tested the following things on Zabbix 2.0 virtual appliance - note this is before the changes to the history screen done by ZBXNEXT-1253 although I still think this issue may exist.

It appears the issue with the timestamp under Monitoring->Latest data>Values is possibly due to the date translation being defined as a constant in defines.inc.php. I don't know much about PHP or GETTEXT but here is what I found, the date translation is referencing a define so in history.php there is this line to format the date:

$table->addRow(array(
					zbx_date2str(HISTORY_ITEM_DATE_FORMAT, $data['clock']),
					zbx_nl2br($value)
				));

So the date format references a constant defined in defines.inc.php:

define('HISTORY_ITEM_DATE_FORMAT', _('Y.M.d H:i:s'));

Now the Russian PO file has this:

#: include/defines.inc.php:878 include/defines.inc.php:879
#: include/defines.inc.php:882
msgid "Y.M.d H:i:s"
msgstr "d.M.Y H:i:s"

So the format is changed to have the day of the month first rather than the year in the Russian translation. However, for the Russian translation only the month abbreviation is translated, not the actual format. See attached image - LatestValuesTranslationNotWorking.png

Then I tried instead of using a define doing this translation in line in the history.php file so instead of referencing HISTORY_ITEM_DATE_FORMAT in history.php now I have:

$table->addRow(array(
					zbx_date2str(_('Y.M.d H:i:s'), $data['clock']),
					zbx_nl2br($value)
				));

then updated the .po file to reference the correct line in history.php and rebuilt the .mo files and this worked correctly. So I think there may be possibly something going on with using a define statement with text that is translated, those dates are the only defines I see that have translated text in them. Possibly the issue is that the defines are actually loaded/set before the translations are, if you look at config.inc.php it requires the define.inc.php which means the defines would be set a that point but inside that config.inc.php source is where the gettext translations are initialized. So the order of initialization in that case is:

1. Set defines <--- translations are not initialized at this point so _('Y.M.d H:i:s') resolves to the default 'Y.M.d H:i:s'
2. Load translations in config.inc.php
3. First time zbx_date2str is called <--- this initializes the static arrays with the month translations, this works because it occurs after translations have been loaded so we can translate August to the proper localized text
4. history.php form loads, translates dates <--- format from default define is used but we can still translate the month due to zbx_date2str initializing after translations have been loaded

That's just my guess as to why that occurs.

This looks to also be true for the events timestamp as well as it looks like it's using the define EVENTS_ACTION_TIME_FORMAT which is not getting formatted based on the translation.

As for the graph navigation bar not having the date translated it appears this is because the format is hardcoded in a javascript source file, see gtlc.js -

// info left
		var date = datetoarray(userstarttime);
		this.dom.info_left.innerHTML = date[0] + '.' + date[1] + '.' + date[2] + ' ' + date[3] + ':' + date[4];

		// info right
		var date = datetoarray(usertime);
		var right_info = date[0] + '.' + date[1] + '.' + date[2] + ' ' + date[3] + ':' + date[4];

		if (this.timeline.now()) {
			right_info += ' (' + locale['S_NOW_SMALL'] + '!) ';
		}
		this.dom.info_right.innerHTML = right_info;

And datetoarray has a pre-determined format:

function datetoarray(unixtime) {
	var date = new CDate(unixtime * 1000);
	var dateArray = [];

	dateArray[0] = date.getDate();
	dateArray[1] = date.getMonth() + 1;
	dateArray[2] = date.getFullYear();
	dateArray[3] = date.getHours();
	dateArray[4] = date.getMinutes();
	dateArray[5] = date.getSeconds();

	for (var i = 0; i < dateArray.length; i++) {
		if ((dateArray[i] + '').length < 2) {
			dateArray[i] = '0' + dateArray[i];
		}
	}

	return dateArray;
}

So the format is always d.m.y h.m

Sorry, not sure why the code macro doesn't work

One solution would be to hardcode the date format instead of using DEFINE constants. This is already the case for about half of the dates in the source, so it would improve consistency

Related issue: ZBX-5430

Fixed in svn://svn.zabbix.com/branches/dev/ZBX-5458

(1) 32734 comment said "introduced new 3rd party JavaScript library". this has to be documented

tomtom CLOSED. after discussions, we decided to get rid of this library.

dateFormater.js
@return return human readable date string
Only JS comment should be changed

TESTED

Fixed in 2.0.5rc1 r32833, 2.1.0 r32837

(2) REOPENED. 3rd party library should be removed.

tomtom RESOLVED in r32920

tomtom CLOSED

(3) In function documentation (clas.cdate.js:54-60) redundant spaces should be removed

And in rows: 73, 77, 80, 83 should be added spaces (For example, "val<10" -> "val < 10")

tomtom RESOLVED in r33021

oleg.egorov CLOSED

(4) In class.cdate.js should be added Polish date format: 'd M Y H:m'

CLOSED (Polish translation mistake)

(5) Please rename functions names, as we discussed.

tomtom RESOLVED in r33021

oleg.egorov CLOSED

TESTED.

But, please remove break in class.cdate.js:112 before merge

tomtom done

Fixed in 2.0.5rc1 r33047, 2.1.0 r33048

some trailing newlines were missing after this
(fix committed)

this resulted in a regression : ZBX-6349

See ZBX-6212

In addition, see, ZBX-6459 and ZBX-6502