Problem with Dzil Dates about cpan-changes HOT 7 CLOSED

I think I'd rather change Dist::Zilla to produce a nicer date format. Who doesn't like ISO8601 these days?

FWIW I use this config:

[NextRelease]
:version = 4.300018  ; for %U
time_zone = UTC
format = %-8V  %{yyyy-MM-dd HH:mm:ss'Z'}d (%U)

from cpan-changes.

You should have posted this one in your answer :-)
https://xkcd.com/1179/

I do find the default from dzil (2013-09-27 15:26:58 Europe/Zurich) better readable I have to admit, than something like 2013-09-16T08:24+02:00. But I do agree, that standards should be used by default, for interoperability.

from cpan-changes.

The change document is meant for humans first and computers second. Human readability should come first.

It seems like it should be pretty easy to recognize a TZ name in place of a time offset.

I do not plan on changing my changelogs to use a numeric offset, ever.

from cpan-changes.

What I have seen from the ISO-Standard after a short glance to Wikipedia: it contains never any whitespace.
If this observation is true I have a proposal:

The Changelog-Spec could just ignore anything after the first whitespace following after the date.
Like this it would parse 2013-09-27 15:26:58 Europe/Zurich as just 2013-09-27.
This is most of the time perfectly enough and leaves developers the freedom to add what ever they like at this line... and it would be ISO compatible.

from cpan-changes.

I just checked the Spec at

https://github.com/bricas/cpan-changes/blob/master/lib/CPAN/Changes/Spec.pod

There it says:

Any text following the Date portion of the Version line will be considered the Release Note

As an example it mentions:

0.01 2013-04-01 Codename: April Fool

So this line:

0.025     2013-09-27 15:26:58 Europe/Zurich

Should actually be fine. 15:26:58 Europe/Zurich Should be taken as a Release Note, because ISO8601 allows no whitespace in the date format.
The message is not in the recommend format seems not to be following the Specs here.
But it gets tricky...

The reason is probably because The "T" marker before the time portion is optional.. If this means that instead of T there can be whitespace, the parser seems to be looking for the timezone as a number, since this is the only thing left according to http://www.w3.org/TR/NOTE-datetime
(If there is a time, there must also be a timezone)
So if your 'Release Note' accidentally starts with something like 22:33 or 11:22:33 the parser seems to think this must be part of the date.
The 'cause' here is that the T marker is optional. This seems very bad, because it is not the standard - at least not ISO8601.
Exactly this exception from the standard makes the dzil-date throw errors.

At least this is my observation from the specs. I have not examined all the code.

from cpan-changes.

Should be fixed in commit 770ee08 and in CPAN-Changes releases 0.24 & 0.25.

from cpan-changes.

Thanks a lot for the effort.

I updated to your newest version, and it worked fine for me. Now we just need to wait until it makes it to http://changes.cpanhq.org/

from cpan-changes.