[External] : Re: RFR: 8231640: (prop) Canonical property storage

[Jaikiran Pai]

Hello Stuart,

On 09/09/21 12:35 am, Stuart Marks wrote:
>
>
>>> 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?
>
> My point in bringing this is up is to consider interoperability. I 
> don't have a strong preference over the particular date format. As far 
> as I can see, there are currently two behaviors "in the wild":
>
> 1) Baseline OpenJDK 17 behavior:
>
>     dow mon dd hh:mm:ss zzz yyyy
>
> This is the behavior provided by "new Date().toString()" and has 
> likely not changed in many years. Of course, the actual values reflect 
> the current time and locale, which hurts reproducibility, but the 
> format itself hasn't changed.
>
> 2) Debian's OpenJDK with SOURCE_DATE_EPOCH set:
>
>     yyyy-MM-dd HH:mm:ss z
>
> The question is, what format should the JDK-8231640 use?
>
> I had said earlier that it might be a good idea to match the Debian 
> format. But thinking about this further, I think sticking with the 
> original JDK format would be preferable. The Debian change is after 
> all an outlier.
>
> So the more specific question is, should we try to continue with the 
> original JDK format or choose a format that's "better" in some sense? 
> It seems to me that if there's something out there that parses the 
> date from a properties file, we'd want to avoid breaking this code if 
> the environment variable is set. So maybe stick with the original 
> format in all cases. But of course for reproducibility use the epoch 
> value from the environment and set the locale and zone offset to known 
> values.

All this makes sense. So I've updated the PR to continue to use the same 
date format that java.util.Date.toString() was using, in both the cases 
- while writing out the current date (in absence of SOURCE_DATE_EPOCH) 
and while writing out the SOURCE_DATE_EPOCH. While writing out the 
SOURCE_DATE_EPOCH, we will however fix the timezone to UTC and locale to 
ROOT for reproducibility.

-Jaikiran