tanks for your answer. Now I think I understand where the problem is. You use some specific PHP funcions which I don't know and I read only the documentation and follow strong it. The problem is that 1330249977 is not the time in miliseconds - it's time in seconds. It corresponds the "U" format. The format "u" is the time in microseconds, but JavaScript need the time in miliseconds. Moreover I find that the documentation of "u" format really misunderstandable. How I could read here the "u" format can be supported by DateTime calss and not the date calss. Moreover it seems be not the total number of ticks, but just the microsecond part of the time. If can be used in the form $d->format("Y-m-d H:i:s.u") where $d is DateTime.

So I suppose that the input value for the "u" format should be integer from 0 till 999. One should convert it to string and include padding 0 if needed. For example the value 43 should be converted to "043". One can additionally cut the traling 0 characters, so to convert 40 to "04" and not as "040". One should not use the "u" value as the part of new Date because JavaScript don't support the resolution. Instead of that one can add decimalSeparator to resulting string and then append the "u" value.

So I agree that my original suggestion is wrong, but I still think that the usage of "u" format in jqGrid is still incorrect.

Another problem is that the current code of jqGrid have all formats oriented on PHP, but other languges use alternative formats as default. Microsoft .NET support serializing of DateTime in the string like \/Date(ticks)\/ and where ticks represents milliseconds since epoch (UTC). It seems that Java or MVC Spring produce just ticks with milliseconds. So the problem is which format can be used to convert the date.

Moreover one use now much more another Date format. The datepicker uses $.datepicker.formatDate and it's very unpractical to support always two different formats. For example newformat: 'd-M-Y' corresponds to dateFormat: 'dd-M-yy' in the datepicker. I think it's more larger problem.

Best regards
Oleg

Thanks again.Right now I have time to look at the new "u" option added in 5.2.2

This tiime I think you have misunderstud the "u" option.

With few words the u option is equal to getMilliseconds javascript function and it can not be used separatley.

In order proff my concept I have creatted simple test in PHP:

echo date("U");

echo date("u");

The second echo return in my demo "000000". I asked myself why?

My investigations go to the following equvalent of date("u") = > microtime()

(note that at PHP site you have point for the date function we have a note:

Note:

Since this function only accepts integer timestamps the u format character is only useful when using the date_format() function with user based timestamps created with date_create().

)

Having this I have two numbers from the following expressins:

echo date("U"); ====>1330249977

echo microtime( true); ====>1330249977.874

Now I pass the numbers to the following expression

var timestamp1 = new Date (1330249977);

var timestamp2 = new Date (1330249977.877);

Both of these return

Date {Fri Jan 16 1970 11:30:49 GMT+0200 (FLE Standard Time)}

Now doing

var timestamp1 = new Date ( parseFloat(1330249977)*100);

var timestamp2 = new Date ( parseFloat(1330249977.877) *1000);

both of these return

Date {Sun Feb 26 2012 11:52:57 GMT+0200 (FLE Standard Time)}

With simple words I think  that the code should not be changed.

If you do not know there is a project called PHP.JS.

You can see how the date formating is represented here for the options u and U:

http://phpjs.org/functions/date:380

Kind Regards

Tony

the constructor of Date with the number as parameter wait for milliseconds: "Integer value representing the number of milliseconds since 1 January 1970 00:00:00 UTC (Unix Epoch)." (see here for example). The same format has "U" format of PHP (see here). If the input is in microseconds which corresponds to "u" format of PHP, then because 1000 microsecond = 1 milliseconds one have to devide the input value to 1000 to have the value in milliseconds required as input of the Date constructor. So I think that the correct should be

Best regards
Oleg

Can not confirm right now, but the expression maybe should look like this:

Regards

Tony

the current implementation of DateFormat from jquery.fmatter.js module supports only 'u' format of input dates which follows to misunderstandnisses (see here and here for example).

PHP destinguish two different date formates: 'u' and 'U' (see here) which are different. The current code uses String(format).toLowerCase() == "u" and interpret both as the same (see here):

I suggest to fix the code to for example the following

Best regards
Oleg

P.S. The code of date formatter in the version 4.1.2 (see here) worked still correctly with 'U' format, but in the version 4.2.0 the new code had alread the described above bug.