sub sortByDate
{
    #get dates. will look like this: date:"2015-02-16",  "YYYY-MM-DD",
    my $aDate = $a =~ /date:\"(\d{4}\-\d{2}\-\d{2})"/;
    my $bDate = $b =~ /date:\"(\d{4}\-\d{2}\-\d{2})"/;

    return ($aDate cmp $bDate);
}
[download]

...should contain...

 
    my($aDate) = $a =~ /date\"(\d{4}-\d{2}-\d{2})"/;
    my($bDate) = $b =~ /date\"(\d{4}-\d{2}-\d{2})"/;
[download]

The regexp binding operator returns true/false (1 or 0) in scalar context, and the match contents in list context. The parens around your variable names place the return value of the =~ operator into list context.

By the way, even for small bits of JSON, I'd be inclined to convert them to a datastructure as the first thing I do, rather than treating the json as text.

Update: An example of treating the data as JSON:

use strict;
use warnings;
use JSON;
use Data::Dump;

my @data;

while (<DATA>) {
    next unless /\N/;
    push @data, decode_json($_);
}

print "Unsorted:\n";
dd \@data;

my @sorted = sort { $a->{date} cmp $b->{date} } @data;

print "\nSorted:\n";
dd \@sorted;

__DATA__
{ "date":"2015-03-01", "content":"asdf" }


{ "date":"2015-05-01", "content":"erwa" }
{ "date":"2015-01-02", "content":"erts" }

{ "date":"2014-04-02", "content":"w34r" }
[download]

...produces the following output:

Unsorted:
[
  { content => "asdf", date => "2015-03-01" },
  { content => "erwa", date => "2015-05-01" },
  { content => "erts", date => "2015-01-02" },
  { content => "w34r", date => "2014-04-02" },
]

Sorted:
[
  { content => "w34r", date => "2014-04-02" },
  { content => "erts", date => "2015-01-02" },
  { content => "asdf", date => "2015-03-01" },
  { content => "erwa", date => "2015-05-01" },
]
[download]

I did have to fix up your JSON, but I assume the real data you are working with is real JSON, not pseudo-JSON as the post seems to show. There are many reasons why I would prefer an approach that treats the input JSON as JSON rather than as strings, including:

• Easy detection of malformed input.
• As the input grows more complex, the solution scales up to encapsulate the complexity; you don't have to invent a new regexp every time the data takes a new turn.
• It's more convenient to deal with data structures internally. We should favor approaches that convert to the most convenient format as early as possible, and convert away from that most convenient format as late as possible... if we value reduced code complexity and fewer bugs.
• Someone has already written a JSON parser; you don't need to.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.