Ovid

Currently RT cannot talk to PAUSE, so I can't submit a bug report for this:

perl -Mutf8::all -MDateTime::Tiny -E \
    'say DateTime::Tiny->from_string("୭୮୯௦-௧௨-௩௪T௫௬:௭௮:௯౦")'
0000-01-01T00:00:00

The problem are these lines from the DateTime::Tiny code:

unless ( $string =~ /^(\d\d\d\d)-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/ ) {
    Carp::croak("Invalid time format (does not match ISO 8601)");
}

Ignoring the fact that DateTime::Tiny uses Carp but doesn't load it, it also falls prey to the well-known problem problem where \d matches Unicode digits, not just ASCII ones. For example, this code:

use utf8::all;
my $num_matched = 0;
for ( 1 .. 2**16 ) {
    my $char = chr($_);

    if ( $char =~ /\d/ ) {
        $num_matched++;
        say "$_ => $char";
    }
}
say "$num_matched characters matched";

Will spew out a lot of strange characters before saying that you've matched 360 "digits".

The fix is to reply all of the \d with [0-9] or, in 5.14 or later, use the new /a modifier which tries to match ASCII only, when appropriate. See perlre for more information.

Since I can't log into RT, I can't file the bug report. However, Adam does offer a repo: svn.ali.as/cpan/trunk/DateTime-Tiny and that's why I didn't submit a patch.

I gave up on Subversion (and CVS) a long time ago. If you offer me a contract, I'll work with whatever source control you use. That's just part of being a professional. However, for the open source world, I am not getting paid and thus, when I contribute to open source, I have a few personal guidelines:

1. The other devs should be pleasant to work with
2. The code base should be relevant to me or at least fun
3. The barrier to entry should be as low as possible

Adam's code passes 1 and 2, but it doesn't pass 3. Using distributed source control systems is, for me, so much easier that I no longer have any desire to work CVS and SVN for unpaid work. I'm not saying it's hard to do, and for this case, it's trivial, but here's what happens with git:

• git clone $project
• # make a change
• git commit @files
• # make a change
• git commit @files
• # make a change
• git commit @files
• Rerun all tests one last time (in case I screwed up)
• git request-pull (or just do it on github)

With Subversion, that above workflow is a pain and, as a result, changes tend to come in one big chunk followed by a svn diff > path/to/monster/patch.

What's worse, if I want to send follow up patches, do I base them on my possibly unaccepted (and uncommitted) ones or do I throw everything away and start from scratch?

I don't need the added hassle. I just want to clone, fix, issue a pull request and have more time to spend with my wife and daughter. Ironically, I spent more time writing this than I would have spent making a patch and mailing him a diff and I feel awkward enough about this that I wrote a test, fixed the code, and am emailing him a patch now (making me a damned liar, I suppose). That being said, when I see open source repos in Subversion, I simply ignore them now. When I had mine in Subversion, I hardly received any patches (and invariably couldn't apply the patch!). Now I receive them all the time since much of my code's on github. I'm not the only one who refuses to mess with Subversion.

Update: ... aaaannnddd my email with the patch bounced. I sent it to two of my email addresses for Adam, but yet another reason to add to the above list.