RFR JDK-8075526: Need a way to read and write time in UTC

[Kumar Srinivasan]

Hi Sherman,

I am good with this.

Thanks
Kumar


On 7/1/2015 3:19 PM, Xueming Shen wrote:
> Hi Kumar, thanks for the comments. Webrev has been updated according.
>
> On 7/1/15 2:09 PM, Kumar Srinivasan wrote:
>> Hi Sherman,
>>
>> Thanks for solving this!, this has been a long standing issue for 
>> pack200.
>>
>> The changes looks generally good, I have also tested the initial 
>> prototype
>> with pack200.
>>
>> Some nitpicks:
>> TestLocalTime.java:
>> 0. line 51, s/supoprt/support/
>> 1. line 63, you have a "}" out of place
>> 2. line 71, misplaced ","
>> 3. line 111: extra LF.
>>
>> Thanks
>> Kumar
>>
>> On 6/30/2015 2:11 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help review and comment on this rfe.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8075526
>>> webrev: http://cr.openjdk.java.net/~sherman/8075526
>>>
>>> Background info:
>>>
>>> The title of the RFE is a little "mis-leading". All the existing 
>>> set/get date-time
>>> methods actually work with "UTC" time. Both the old pair
>>>
>>> public void setTime(long time);
>>> public long getTime();
>>>
>>> and the newly introduced pair
>>>
>>> pubic ZipEntry set/getLastModifiedTime(FileTime time);
>>> public FileTime getLastModifiedTime();
>>>
>>> are to set/get the last modified time in UTC time. However the ZIP 
>>> specification
>>> clearly specifies that the "normal" date and time fields in the zip 
>>> file entry (loc and
>>> cen) are defined as the date/time in dos format, which unfortunately 
>>> is a "local"
>>> date-time. Therefor timezone conversion must be applied before/after 
>>> the utc time
>>> can be set into/got from those fields (the UTC timestamps set/get by 
>>> the new pair
>>> are therefor being set into/got from the "extended timestamp fields" 
>>> of the optional
>>> extra data of each entry, those fields are specified as unix/utc 
>>> timestamp)
>>>
>>> We did not have an "local-date-time" abstract before the 
>>> java.time.LocalDateTime
>>> was introduced in jdk8, the epoc date/time is the only date/time 
>>> abstract in java
>>> vm.
>>>
>>> The proposed change here is to add yet another pair of set/get 
>>> modified time methods
>>>
>>> public void setTimeLocale(LocalDateTime time);
>>> public LocalDateTime getTimeLocal();
>>>
>>> to use the java.time.LocalDateTime type to set/get the modified time 
>>> into zip entry's
>>> dos timestamp fields directly WITHOUT involving the timezone 
>>> conversion (implied, with
>>> default TimeZone).
>>>
>>> Other than solving the pack/unpack problem raised in this RFE, it 
>>> should also help improve
>>> the performance when local-date-time is actually desired when 
>>> interfacing with the ZipEntry
>>> by eliminating the un-necessary/implied timezone conversion. For 
>>> example, in our jar tool,
>>> currently we are "printing" the timestamp for zip entry "e" as
>>>
>>>     new Date(e.getTime()).toString();
>>>
>>> in which we are converting the local-date-time (ms-dos-formatted in 
>>> zip entry) to utc time
>>> by using the default timezone (in ZipEntry), and then converting the 
>>> utc time (in Date) back
>>> to the printable "local date time" again.
>>>
>>> It might be desired to format the "local-date-time" directly without 
>>> involving the timezone
>>> conversion now via the proposed method
>>>
>>> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss 
>>> zzz yyyy")
>>> .withZone(java.time.ZoneId.systemDefault());
>>> .format(e.getTimeLocal()
>>>
>>> In above example, we still use the "system default timezone", 
>>> however, it is used
>>> purely to output the zone name for the "zzz" (which the 
>>> Date.toString() does), not for conversion.
>>> if the "zzz" is not required/needed, it can just be
>>>
>>> java.time.format.DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss 
>>> yyyy").format(e.getTimeLocal());
>>>
>>> Comment/Opinion please. If we agree the approach/webrev, I will 
>>> submit the CCC before integration.
>>>
>>> Thanks,
>>> -Sherman
>>>
>>
>