in reply to Date Manipulation Calculation Question

Most everyone has replied with some form of "Convert it to seconds, do the math, convert it back again". This is an entirely acceptable answer, and absent any other requirements this is what I would do.

There is, however, a possible reason not to do this if performance is an issue. Note that there would have to be a really good reason to do it this way, but here goes.

Converting a string such as 20041101174146 to a number of seconds would take at least 6 mathematical operations for the 2004, 11, 01, 17, 41, and 46 components. Converting it back again will take another 6, then there's either the string splitting or modulus operations to break it up, and the opposites to put it back again. This could entail 25 discrete steps.

In most cases, and certainly with the example above, this can be done with a substring, a subtract, a test for undererflow, and an assignment back to the substring. It is possible that adding a value to a time string such as the above could cause 5 overflows (19991231235959 + 1 second = 20000101000000), and this case would take considerably more computation than the generic convert-to-seconds approach, but in most cases there should be a performance gain.

  • Comment on Re: Date Manipulation Calculation Question - performance alternative

Replies are listed 'Best First'.
Re^2: Date Manipulation Calculation Question - performance alternative
by demerphq (Chancellor) on Nov 02, 2004 at 14:24 UTC

    Converting a string such as 20041101174146 to a number of seconds would take at least 6 mathematical operations for the 2004, 11, 01, 17, 41, and 46 components.

    Well, one thing to recall here is that if the operation occurs regularly then caching the results will result in a signifigant speedup. For instance you could cache the year/month/day/hour results and then add in only the minutes and seconds. This means that a lot of the operations you mention here wouldn't have to happen unless the cache was empty and even then would only happen once.

    After a LOT of benchmarking I found the following routine works best for my situation (parsing millions of datestamps a day), obviously other usage cases may have different performance effects. 

    {
    my (%hourcache,%mincache);
    sub D14_to_unix {

        my $hour = substr( $_[0], 0,  10 );
        my $min  = substr( $_[0], 10, 4 );
        return +( $hourcache{$hour} ||= 
                    timelocal( 00,
                               00,
                               substr( $hour, 8, 2 ),
                               substr( $hour, 6, 2 ),
                               substr( $hour, 4, 2 ) - 1,
                               substr( $hour, 0, 4 ) - 1900
                             )
        ) + ( $mincache{$min} ||= 
              ( substr( $min, 0, 2 ) * 60 + substr( $min, 2, 2 ) ) 
            );
    }
}

    [download]
    ---
    demerphq

[reply]
[d/l]

In Section Seekers of Perl Wisdom