Home/ Questions/Q 3272706
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T18:51:15+00:00

I am doing some large timestamp-list iterations: Putting them in tables with date-ranges ,

  • 0

I am doing some large timestamp-list iterations: Putting them in tables with date-ranges, and grouping them by ranges.
In order to do that, I found strtotime() a very helpfull function, but I am worried about its performance.

For example, a function that loops over a list of weeks (say, week 49 to 05) and has to decide the beginning of the week and the timestamp at the end of that week. A usefull way to do that, would be:

foreach ($this->weeks($first, $amount) as $starts_at) {
  $ends_at = strtotime('+1 week', $starts_at);
  $groups[$week_key] = $this->slice($timestamps, $starts_at, $ends_at);
}

//$this->weeks returns a list of timestamps at which each week starts.
//$this->slice is a simple helper that returns only the timestamps within a range, from a list of timestamps.

Instead of strtotime(), I could, potentially, find out the amount of seconds between begin and end of the week, 99% of the times that would be 24 * 60 * 60 * 7. But in these rare cases where there is a DST-switch, that 24 should either be 23 or 25. Code to sort that out, will probably be a lot slower then strtotime(), not?

I use the same patterns for ranges of years, months (months, being very inconsistent!), days and hours. Only with hours would I suspect simply adding 3600 to the timestamp is faster.

Any other gotcha’s? Are there ways (that do not depend on PHP5.3!) that offer better routes for consistent, DST and leap-year safe dateranges?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Why are you worried about its performance? Do you have evidence that it’s slowing down your system? If not, don’t try to over-complicate the solution for unnecessary reasons. Remember that premature optimization is the root of all evil. Write readable code that makes sense, and only optimize if you KNOW it’s going to be an issue…

    But something else to consider is that it’s also compiled C code, so it should be quite efficient for what it does. You MIGHT be able to build a sub-set of the code in PHP land and make it faster, but it’s going to be a difficult job (due to all the overhead involved in PHP code).

    Like I said before, use it until you prove it’s a problem, then fix that problem. Don’t forget re-writing it for you needs isn’t free either. It takes time and introduces bugs. Is it worth it if the gain is minimal (meaning it wasn’t a performance problem to begin with). So don’t bother trying to micro-optimize unless you KNOW it’s a problem…

    • 0