[rfc][icedtea-web] Fix to PluginMessage dates for PR2063

[Jiri Vanek]

>>
>> Yes , I vote for v1 deffinitely.
>>
>> However - the sorting in consoel could not work for you - have youtried!?!?!?
>>
>> Tehre is:
>>                   case 4:
>>                       Collections.sort(sortedData, new
>>                       CatchedMessageWithHeaderComparator() {
>>                           @Override
>>                           public int body(MessageWithHeader o1,
>>                           MessageWithHeader o2) {
>>                               return
>>                               o1.getHeader().date.compareTo(o2.getHeader().date);
>>                           }
>>                       });
>>
>> You  had to got compley insane results....
>>
>>
>>
>> I think the fix must go deeper.
>>
>> What I consider as best fix is:
>> in console ouput (in header is on) to have the  most correct "result of
>> main[4]" //rfc
>> However, the sorting operation must be done against originalTimeStamp . hmm.
>> I would like to test,
>> if there canbe case when the originalTimeStamp and p.date may have really
>> different (eg by hours or
>> more)  values....
>
> Hello,
>
>
> Hmm. Well I did a patch that covers the sorting (attached), but I noticed that itw-applet messages don't get localized:
>
> [jkang][ITW-APPLET][MESSAGE_DEBUG][Fri Nov 14 17:49:28 CET 2014]
> [jkang][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 14 17:49:08 CET 2014]
>
>
> Should we also localize the java dates too? I think then version 2 will be better, since the java date localization != strftime localization:
>
> e.g:
> cs_CZ
>      Út lis 04 09:02:52 EST 2014 : strftime format
>      Út XI 04 09:02:52 EST 2014 : java date format
>
> I think it will be much harder to convert java date -> strftime date, as opposed to strftime date/timestamp -> java date.
>
>
> Ugh.. Or can we leave as is...
>
>
>
> Regards,
>
>
>
>>

Hi!

The patch looks almost good - *almost* :)

I really do not understand :
+            p.timestamp = new Date(Long.parseLong(init[1]) / 1000).getTime();

Why to long to date  and then to long again???

Anyway - I think we should stay with date Instead of:


-    public Date date = new Date();
+    public String date;
+    public Long timestamp;

I would go with


-    public Date date = new Date();
+    public String date;
+    public Date timestamp;


NIt:

+            p.date = main[4];
+
+
imho one  \n is enough :)



After the long->date->long is fixed and
-                            return o1.getHeader().date.compareTo(o2.getHeader().date);
+                            return o1.getHeader().timestamp.compareTo(o2.getHeader().timestamp);
                          }
you are sure returns correct order, it seems to be ok for head. But please send one more times.


J.