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

[Stuart Marks]

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

s'marks