Problem with Dzil Dates #17

borisdaeppen opened this Issue Sep 27, 2013 · 7 comments


None yet

4 participants


I would like to include Test::CPAN::Changes in the xt directory of my distribution
However I have problems.

First the links to the relevant files:

The problem occurs because of the date-format. However I use Dist::Zilla for this. The dates are created how dzil thinks they should be.

When I now run the test-suit like so prove -Ilib xt/changes.t, I get errors similar to this one for each entry:

xt/changes.t .. 1/4 Date "2013-05-27 16:44:00 Europe/Berlin" is not in the recommend format at /home/perl/perl5/perlbrew/perls/perl-5.16.3/lib/site_perl/5.16.3/Test/CPAN/ line 28.

However this stuff is just verbose... prove tells me that tests passed: All tests successful.

I do think it would be great if the defaults of dzil would play nice with the standards, set by this lib. But I don't know at which point we should introduce any Changes. Is the standard here just to strict? Or does dzil rely on false stuff.


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:

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

You should have posted this one in your answer :-)

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.


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.


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.


I just checked the Spec at

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
(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.


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

@bricas bricas closed this Oct 8, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment