RFR: 8231640: (prop) Canonical property storage

[Jaikiran Pai]

Hello Stuart,

On 08/09/21 6:49 am, Stuart Marks wrote:
>
>
> On 9/7/21 8:27 AM, Jaikiran Pai wrote:
>>
>> On 07/09/21 8:35 pm, Roger Riggs wrote:
>>>
>>> Though java.util.Date is used in the current implementation, its use 
>>> is discouraged in new code
>>> in favor of java.time.ZonedDateTime.
>>> Consider if java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME 
>>> can be used to parse and format the time.
>>
>> Noted. I'll take a look at these and update the PR as necessary.
>
> Unless there's an overriding reason, it might be nice to have the 
> output format match the format used in the Debian patch that adds 
> SOURCE_DATE_EPOCH:
>
> https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproducible-properties-timestamp.diff 
>

So the current patch implementation uses the format "d MMM yyyy HH:mm:ss 
'GMT'", with a Locale.ROOT (for locale neutral formatting). I chose this 
format since that was the one that the (deprecated) 
java.util.Date#toGMTString() was using.

Roger's suggestion is to use DateTimeFormatter#RFC_1123_DATE_TIME date 
format which is "dow, d MMM yyyy HH:mm:ss GMT" (where dow == day of week)

IMO, either of these formats are "well known", since they are/were used 
within the JDK, especially the DateTimeFormatter#RFC_1123_DATE_TIME 
which Roger suggested, since that's even a public spec.

The one in the debian patch is "yyyy-MM-dd HH:mm:ss z" which although is 
fine to use, it however feels a bit "less known".

I was leaning towards Roger's suggestion to use the RFC_1123_DATE_TIME 
in my upcoming patch update. Is there a reason why the one in debian's 
patch is preferable compared to a spec backed format?

-Jaikiran