Forum
11:13
10/08/2009
Hello 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):
//Unix timestamp
timestamp = new Date( parseFloat(date)*1000 );
I suggest to fix the code to for example the following
// 'U' – Seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)
// 'u' – Microseconds (added in PHP 5.2.2)
timestamp = new Date( parseFloat(date)*(String(format) === "u" ? 1000 : 1));
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.
16:25
Moderators
30/10/2007
Thanks Oleg,
Can not confirm right now, but the expression maybe should look like this:
..
timestamp = new Date( parseFloat(date)*(String(format) === "U" ? 1000 : 1));
Regards
Tony
For professional UI suites for Java Script and PHP visit us at our commercial products site - guriddo.net - by the very same guys that created jqGrid.
17:28
10/08/2009
Hi 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
12:04
Moderators
30/10/2007
Hello 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
For professional UI suites for Java Script and PHP visit us at our commercial products site - guriddo.net - by the very same guys that created jqGrid.
16:25
10/08/2009
Hello Tony,
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
Most Users Ever Online: 715
Currently Online:
46 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
OlegK: 1255
markw65: 179
kobruleht: 144
phicarre: 132
YamilBracho: 124
Renso: 118
Member Stats:
Guest Posters: 447
Members: 11373
Moderators: 2
Admins: 1
Forum Stats:
Groups: 1
Forums: 8
Topics: 10592
Posts: 31289
Newest Members:
, razia, Prankie, psky, praveen neelam, greg.valainis@pa-tech.comModerators: tony: 7721, Rumen[Trirand]: 81
Administrators: admin: 66