LPM: The times they are a-changin' (or: integer hash keys)

[Gregg Casillo]

My first (and presently only) idea would be to zero-pad those numbers so 
that they are a uniform length and thus will sort correctly. So if you 
have numbers like 3, 9, 10, 22, and 105, zero-pad them: 003, 009, 010, 
022, and 105. Use sprintf():

$padded = sprintf("%03d", 23); # $padded = 023;

I don't know how feasible it would be to go back and zero-pad all of 
your numbers in question though.

Interesting,
Gregg


David Hempy wrote:

>     
> Well, since Y2K was such a fizzle, we get another chance at notoriety 
> on September 8, 2001, when we exceed 999,999,999 seconds since the 
> epoch.  Shouldn't be a big deal, as that's only one less than 
> 1,000,000,000 seconds.
>
> But yet, I'm facing it in one of my programs...
>
> I got a call from a user complaining that September 8th's program 
> schedule was out of order.  Everything after 9:30 PM (EDT) showed up 
> first, before our first show at 8:00 AM.  Sure enough, she was right:
>
> http://edit-www.ket.org/cgi-plex/schedule/ribbon_funnytime.pl?date=2001-09-08 
>
>
>
> It didn't take too long to figure notice the coincidence between the 
> sorting problem and the 9+1 issue.  After convincing myself that SQL 
> Server didn't know how to sort these values correctly (duh) I looked 
> at my own code.
>
> Turns out the problem was actually me not understanding how hash keys 
> work.  I was using epoch times as hash keys.  It appears that hash 
> keys are stored as strings, not the integers I was expecting.  For 
> example:
>
> $foo{1} = "one";
> $foo{2} = "two";
> $foo{3} = "three";
> $foo{10} = "ten";
> $foo{20} = "twenty";
> $foo{30} = "thirty";
>
> foreach my $key (sort keys %foo) {
>     print "$key - $foo{$key}\n";
> }
>     
>
> This produces this output:
> 1 - one
> 10 - ten
> 2 - two
> 20 - twenty
> 3 - three
> 30 - thirty
>
>
> Any suggestions on a good way to sort hash keys by their integer values?
>
>
> -dave
>