Bug #87499 for CPAN-Changes: please allow s/T/\x20/ in the date field

Wed Jul 31 17:01:39 2013 rjbs [...] cpan.org - Ticket created

Subject:

please allow s/T/\x20/ in the date field

I like YYYY-MM-DD HH:mm just fine. I really like it, actually. There is no way in heck, though, that I'm ever putting that T in there. Ever. Really. Changelog files are for humans, and humans are going to have a harder time dividing things on the T than on a space. -- rjbs

Wed Jul 31 17:09:15 2013 ether [...] cpan.org - Correspondence added

On 2013-07-31 14:01:39, RJBS wrote: Show quoted text

> I like YYYY-MM-DD HH:mm just fine. > > I really like it, actually. > > There is no way in heck, though, that I'm ever putting that T in > there. Ever. Really. > > Changelog files are for humans, and humans are going to have a harder > time dividing things on the T than on a space.

I would greatly appreciate the checking not being done on the entire line, but only on the bits that match the regexp (e.g. up to just the date, if the stuff after the date doesn't match), to allow for more flexibility in how times are indicated. For example, some do this (from Dist::Zilla::Plugin::Test::Compile): 2.013 2013-07-30 20:54:52 Europe/Paris and others do this (from Dist::Zilla::PluginBundle::Author::ETHER): 0.014 2013-07-29 17:25:48 PDT-0700 (Karen Etheridge) ...and both are very much equally machine- and human-parsable with the standard YYYY-MM-DD HH::mm::ss.

Wed Jul 31 17:09:16 2013 The RT System itself - Status changed from 'new' to 'open'

Sun Aug 04 10:59:55 2013 bricas [...] cpan.org - Correspondence added

On Wed Jul 31 18:01:39 2013, RJBS wrote: Show quoted text

> I like YYYY-MM-DD HH:mm just fine. > > I really like it, actually. > > There is no way in heck, though, that I'm ever putting that T in > there. Ever. Really. > > Changelog files are for humans, and humans are going to have a harder > time dividing things on the T than on a space.

This should now be fixed in git [1]. It includes a spec update, plus tests to make sure these dates pass our validation regex. -Brian [1] https://github.com/bricas/cpan-changes/commit/ffd70efa52758800c152d84505b72cfbeff33f5f

Sun Aug 04 11:03:08 2013 bricas [...] cpan.org - Correspondence added

On Wed Jul 31 18:09:15 2013, ETHER wrote: Show quoted text

> I would greatly appreciate the checking not being done on the entire > line, but only on the bits that match the regexp (e.g. up to just the > date, if the stuff after the date doesn't match), to allow for more > flexibility in how times are indicated. For example, some do this > (from Dist::Zilla::Plugin::Test::Compile): > > 2.013 2013-07-30 20:54:52 Europe/Paris > > and others do this (from Dist::Zilla::PluginBundle::Author::ETHER): > > 0.014 2013-07-29 17:25:48 PDT-0700 (Karen Etheridge) > > ...and both are very much equally machine- and human-parsable with the > standard YYYY-MM-DD HH::mm::ss.

I'm pretty sure we've always tried to pull out the dates we recognize and leave the rest. I'm 100% sure this is the case since version 0.21. Everything else after the date is now considered the "note." -Brian

Sun Aug 04 11:03:18 2013 bricas [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Aug 10 17:16:44 2013 ether [...] cpan.org - Correspondence added

Could this please stay in the 'patched' state until it is actually released, so when it is released, the changing of state to 'resolved' will let us know that we can install the fix? thanks!

Sat Aug 10 17:16:44 2013 ether [...] cpan.org - Status changed from 'resolved' to 'open'

Sat Aug 10 17:17:03 2013 ether [...] cpan.org - Requestor ETHER added

Wed Aug 14 22:23:46 2013 bricas [...] cpan.org - Correspondence added

CPAN::Changes 0.23 released to CPAN.

Wed Aug 14 22:23:47 2013 bricas [...] cpan.org - Status changed from 'open' to 'resolved'