|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #66295 fetch_timezone_offset has poor performance
Submitted: 2013-12-15 01:37 UTC Modified: 2021-04-07 15:59 UTC
From: ben dot maurer at gmail dot com Assigned: cmb (profile)
Status: Closed Package: Date/time related
PHP Version: Irrelevant OS: N/A
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: ben dot maurer at gmail dot com
New email:
PHP Version: OS:


 [2013-12-15 01:37 UTC] ben dot maurer at gmail dot com
fetch_timezone_offset does a linear search through the list of time transitions. Many timezones have a rather large number of transitions. Eg, Pacific time appears to have ~180 transitions.

One possible solution might be to do a binary search rather than a linear search of the list of times. But a simpler solution could be to do a search backwards in the array: most people probably do manipulation of recent rather than old dates

I tested this using HHVM, which uses the same upstream timezone code as PHP.

Test script:
for ($i = 0; $i < 10000000; $i ++) date('I');

Expected result:
figuring out the DST rules should not be a perf issue

Actual result:
perf record shows timelib_get_time_zone_info taking a substantial amount of time


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-03-29 17:11 UTC]
-Package: timezonedb +Package: Date/time related
 [2021-04-07 15:59 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2021-04-07 15:59 UTC]
This is impemented[1] as of timelib 2021.3, so should be in PHP

[1] <>
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed May 31 16:03:37 2023 UTC