On 2021-09-10 03:57, Jaikiran Pai wrote:
Would this system property have a value that represents what
SOURCE_DATE_EPOCH environment variable would have contained? i.e. it
is the "A UNIX timestamp, defined as the number of seconds, excluding
leap seconds, since 01 Jan 1970 00:00:00 UTC."? So users can
potentially do -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}?
Or would this system property be just some kind flag, which when
having a value of "true" would expect the java.util.Properties code to
lookup the SOURCE_DATE_EPOCH environment variable and use that value
from the environment variable?
I'm guessing it's the former where the value is the number of epoch
seconds, but just wanted to be sure before I do this change.
Actually, why don't we define it as a free-form string instead? That way
the onus is on the user setting the property to get it formatted the way
they want. If they want a backwards-compatibly formatted string for
SOURCE_DATE_EPOCH, they'd have to call Java with an argument something
along the lines of:
-Djava.util.Properties.storeDate="$(date --date=@${SOURCE_DATE_EPOCH}
+"%a %b %d %H:%M:%S %Z %Y")"
which is not much more terrible than
-Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}
given that we in any case won't be reading SOURCE_DATE_EPOCH directly.
This also allows for the user to just skip the date completely:
-Djava.util.Properties.storeDate=""
By changing this property from a epoch based long to a string, all
formatting and verification gets removed from your patch, and it is
greatly simplified.
/Magnus
