php[architect] magazine has shared a column from their July 2017 issue, "Education Station" by Matthew Setter, looking at the use of Period for date and time handling.

For the longest time, I’ve enjoyed using PHP’s DateTime library. I’ve always found it to be relatively straightforward in creating DateTime objects for use with various applications I’ve written.

However, one thing that isn’t very simple, nor intuitive, is the ability to create time ranges—especially ones requiring some degree of sophistication, such as fiscal quarters, for financial reporting requirements. [...] It’s for [code reuse] reasons that I’m going to spend the [end] of the column introducing Period, a Time range API for PHP, maintained by The League of Extraordinary Packages.

He starts off by showing how to do things "the hard way" with the built-in PHP DateTime handling and how difficult it can be to work with ranges. In his example he tries to get the dates for a "quarter", a portion of a year usually used for business reporting purposes. He works through some of the issues he faced during the date calculations and things lie leap years and odd date ranges. He then introduces Period as a way to help solve some of these problems. He lists out the main goals of the project, installing the package and using it to get the same "quarter" dates as his attempt before.

In his latest post Sameer Borate looks at a library he's recently found that's helpful for working with dates and times, even easier than the DateTime handling built into PHP. The Periodlibrary, part of The League of Extraordinary Packages, aims to "resolve many recurrent issues around time range selection and usage."

Date/time programming is one of the tricky aspects of software development. Although inherently not complex in itself, coding date/time algorithms can be a subtle source of bugs. Especially in web development a feature such as payment subscription processing that ranges from days to weeks to months can get complex quickly. Also such kind of scenarios require additional features like auto renewal, scheduled email alerts to subscribers etc. Such kind of features require good date/time handling algorithms and libraries that handle such chores are always welcome. One such library I encountered recently is Period.

He walks you through the basics first - getting the library installed and creating a new instance of the class to work with. He goes through each of the methods available including the constructor, getting the duration between times and getting the start/end values back as DateTime objects. He also looks at the methods that allow you to create the ranges from various time frames (quarters, weeks, etc), compare ranges and modify time ranges that already exist.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.