On Tue, 30 Nov 2021 16:26:28 GMT, John Neffenger <jgn...@openjdk.org> wrote:
> > So what you suggest sounds reasonable, although it would be a "behaviour > > change" in that whereas now if the date is between 1980->2106 only a > > xdostime is stored, we would now always be storing the additional "mtime" > > field ... > > No, sorry, that is not at all what I suggested. > > I am suggesting to immediately convert the value of the `--date` command-line > option to an `Instant`. Once you have an `Instant` object, it's just like > before when you had the value of `SOURCE_DATE_EPOCH` (which is in fact an > instant on the time line), so you can revert to using your prior revision > that handled that situation just perfectly! > > In fact, you always want to avoid storing the addition "extended timestamp" > field when possible because it causes a rather surprising increase in the > size of the archive. > > I wanted to send this right away, because you're such a fast coder, and in a > different time zone, but please give me some time to look over your and > Jaikiran's comments in more detail this morning. Thanks! 😄 @jgneff John, sorry got confused, but I see what you're saying now. So what you're saying is take the --date <iso8601>, work out a LocalDateTime for that "instant" but in UTC, then call e.setTimeLocal(localDateTime). So I think i'm in fact just putting together a new commit for option (1) using setTimeLocal() similar to this, just very slightly different but efftecively doing the same thing, i'm converting the user input --date string to a ZonedDateTime, from which I get the LocalDateTime for calling setTimeLocal(zonedDateTime.toLocalDateTime()). That way when you unzip it the files have the same local date time. eg. --date="2022-03-15T14:36:00+06:00" ------------- PR: https://git.openjdk.java.net/jdk/pull/6481
