RFR: 8231640: (prop) Canonical property storage
jai.forums2013 at gmail.com
Wed Sep 8 02:09:28 UTC 2021
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
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?
More information about the core-libs-dev