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

Kumar Srinivasan kumar.x.srinivasan at oracle.com
Wed Jul 1 21:09:10 UTC 2015

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:
0. line 51, s/supoprt/support/
1. line 63, you have a "}" out of place
2. line 71, misplaced ","
3. line 111: extra LF.


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

More information about the core-libs-dev mailing list