On May 12, 2011, at 10:06 AM, Anders F Björklund wrote: > Jeff Johnson wrote: > >> Should the date in %changelog also be changed? > > You mean for the .spec input ? Wouldn't that invalidate > all spec files, unless it's made "optional" (either/or) ? >
Yep, "incompatible" (invalidate seems to hint that ther is an
agenda which doesn't exist) is why never done.
> Well, I live in a civilized country which uses ISO dates...
> But there's plenty of "middle-endian" date formats in use.
>
>> Or leave bad enuf alone for status quo ante "compatibility"?
>
> The big problem with the timestamps isn't the order, but
> the lack of a timezone. Usually meaning "localtime", but...
>
Timezone really isn't too hard to solve in spewage:
Everything in UTC always.
and convert to local timezone however/whenever you please.
> For the YAML timestamp, I think a missing timezone _might_
> be interpreted as UTC which means the day could be off by one.
>
The "UTC always" enforcement can be done outside of YAML. And
there's little lossage in the format choosing to always add UTC.
Slicker would be to make "UTC always" a rule (it is since forever
for all RPM timestamps, anything not in UTC is a bug), and reduce
the markup redundancy, as well as the eye scratchiness, but ...
>> BTW, RPM got reamed years ago because %changelog isn't "standard", been
>> on my todo++ since forever.
>
> The "author" fields are also horribly abused since forever,
> but seperating out the release at this point might be hard ?
>
Yep. The added version is exploiting a bug in the RFC-822 e-mail parser.
> But for the timestamp I was just going with "canonical",
> seems like if you use a space it means "1 date + 1 time".
>
While there's all sorts of peripheral issues with date/time.
I was more asking
Should spewage attempt typing (like date/time) or just stick with integers?
Lots of the peripheral issues disappear if its just an integer written
into spewage.
OTOH, integers are not very informative when read or grep'ed.
I still don't have my own clear answer, and both your changes
to YAML, and my changes to JSON are headed towards adding
date/time types in the spewage, which is going to open
up all the usual peripheral issues.
Either integers/types "works". I 'spose that explicit times is
easier to perceive as a "feature" ...
73 de Jeff
> --anders
>
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
