date/strtotime poor performance - further digging (v 5.4.9)

So, I've been going through the internals of date() and related, trying to isolate where some poor performance is, to try and find ways to optimize it. In doing so, I came across this: On line 863 of ext/date/php_date.c is this code: } else if (*DATEG(default_timezone) && timelib_timezone_id_is_valid(DATEG(default_timezone), tzdb)) { I noticed it's checking every time that the timezone is "still" valid. Commenting this out results in a tremendous speed increase. From my tests before, I saw 3.3 seconds for strtotime, and 1.75s for date. After commenting out the timelib_timezone_id_is_valid check above, speed increased to 2.3s and 1.2s respectively! (Tests are run 1 million times each) It immediately jumped out at me, because on a few lines prior is initializes DATEG(default_timezone) and checks to make sure it's valid there. Additionally, in PHP_FUNCTION(date_default_timezone_set) it also checks to ensure it is a valid timezone. Having only glanced at what ini_set() does internally, I can presume this check is there to prevent a bad value being set via that command? However, I'm not certain it directly writes the value to DATEG(default_timezone), so it may not be relevant at all. If it does, some better cursory bounds checking in ini_set() might save a lot of redundant bounds checking during runtime calls. It would also make more sense to error them out on the ini_set() line rather than on a date() call that was the result of an improperly configured value. Rather than spending time digging into that when it may not be applicable I figured I'd ask here if anyone is more familiar with the inner-workings of ini_set and other globals that can give me some insight into this? Seems like an easy optimization to make, if I'm not missing something else. Thanks!