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

[Xueming Shen]

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
>>
>