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

[Jiri Vanek]

On 11/18/2014 06:46 PM, Jie Kang wrote:
>
>
> ----- Original Message -----
>>>>
>>>> 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.
>
> Hello,
>
> I've added all the fixes you suggested. Thanks for the review! How does it look?
>
>

Yup. Looks ok for head.

I will play with it tomorrow and if better then ok, then I will backport to 1.5 and prepare 1.5.2 release candidate for testing.

Thank you VM!

J.