Re: [iola-conversion-tool] Incorrect time stamps in the History trail for recently-published RFCs

[Ole Laursen <[e-mail]>]

2012/3/1 Ole Laursen <[e-mail]>:
> There's a slight problem with the IESG state, it doesn't set that to
> published, we need to get that fixed although I don't think you can
> actually see it on the document pages.

I've fixed that so if it is RFC Ed Queue, it'll set it to RFC
published automatically.

>> Bug: In the history trails of the RFCs that were published in the last two days, it shows the RFC as being published on 2012-02-01, rather than 2012-02-29 or 2012-03-01:
>>
>> https://datatracker.ietf.org/doc/draft-lear-iana-timezone-database/history/
>> https://datatracker.ietf.org/doc/draft-irtf-hiprg-dht/history/
>> https://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/history/
>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/
>> https://datatracker.ietf.org/doc/draft-stone-mgcp-vbd/history/
>>
>> And strangely, for draft-ietf-6man-3627-historic, the history trail does not include an "RFC Published" message from the system at all (although the doc page itself does have a link to the RFC):
>>
>> https://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/history/

A careful look at this reveals that it's using 2012-02-01 too, so the
entry ends up below in the stack.

For all of these, I've looked at the actual data, and although the
parser gives me a specific date, the data from the RFC Editor only
says "February 2012". So it just assumes it's the first day of the
month. Gah.

Does anyone know whether we could get the actual date out of the RFC
Editor? I can imagine a couple of other hacks to improve on the
first-day-of-month-assumption, but by far the most robust thing would
if the downloaded data just told us it.


Ole