BOM (byte-order mark) in office_hours.feeds.inc after cache clear

Just a quick note, while it looks like this patch removes and then adds an identical <?php open tag, the BOM is in there (first character in the office_hours.feeds.inc file).

It's not the easiest to spot because in most editors it just doesn't appear.
In an editor such as netbeans, you can see the byte-order mark right before the PHP tag (either in my patch file or office_hours.feeds.inc) as below example:
Netbeans BOM showing

While inspecting the response headers one can also see the offending char:
Inspecting headers
(note the red dot before doctype in the inspector)

The result is (usually) whitespace right before any page content gets loaded after a cache clear (and some interesting w3c validator results), such as:
Result

Steps to replicate would be:
- Give a site a coloured header, or something that would be noticeable if it were moved down a line.
- Use drush to clear caches (the whitespace is well hidden by admin menu, so hard to detect when using admin backend to clear caches)
- Load a page.

It's usually not a huge issue, however, if this first pageload is done by an anonymous user on a site sitting behind a caching server, the BOM causing the whitespace will also be cached. Thus present until caches are cleared, and the first page-load done by an auth'd user.
I'm not entirely sure why it only happens on the very first page load, but applying the patch and then clearing caches will address the issue.

An easy way to spot files with this pesky char in future is running (at the root of your code dir):
grep -rl $'\xEF\xBB\xBF' .

Hope this explains what I'm getting at, as I notice that opening the patch file in a web browser looks like I'm replacing an identical line haha!

Let me know if anything's unclear!
Thanks,
Paul