On the php[architect] site they've shared an article from their December 2018 edition by Colin DeCarlo and issues with dates and times that most developers deal with at some point in their careers.

As applications scale and gain adoption, dates and time become much more of a concern than they once were. Bugs crop up, and developers start learning the woes of time zones and daylight saving time. Why did that reminder get sent a day early? How could that comment have been made at 5:30 a.m. if the post didn’t get published until 9:00 a.m.? Indiana has how man time zones?!

Luckily, PHP developers have the tools they need to face these problems head-on and take back control of their apps.

The article covers some of the basics of "time" and some of the concepts that PHP uses to measure it. It then introduces the different time functionality that PHP offers including timestamps and functions like strtotime and date as well as the DateTime handling. They dig into this last one in more detail before talking about timezones and date arithmetic.

On the Laravel News site there's a new post sharing information about an upcoming upgrade for the framework's date handling. In Laravel 5.8, there's plans to update the Carbon library to v2.

Thanks to Carbon maintainer @kylekatarnls you will be able to use Carbon 1.0 or Carbon 2.0 staring in Laravel 5.8. The update includes the ability to use Carbon immutable and even make your application use CarbonImmutable as the default.

[...] According to the laravel/framework pull request you can choose which class you want for dates “such CarbonImmutable, Chronos or simply DateTime.”

For those that want to transition to using some of the features Carbon v2 provides, they've linked to an upgrade guide and some information about how localization will change as a re result of the upgrade.

On the TutsPlus.com site they've posted a tutorial (by author Monty Shokeen) covering the use of PHP's built-in functionality to format date and time values such as the current date.

You'll often want to work with dates and times when developing websites. For example, you might need to show the last modified date on a post or mention how long ago a reader wrote some comment. You might also have to show a countdown of the days until a special event.

Luckily, PHP comes with some built-in date and time functions which will help us do all that and much more quite easily.

The tutorial starts with the basics of datetime handling in PHP, making use of the date function to get formatted output of either the current time or the timestamp provided. Several code examples are provided showing the output for month/day/year and hour/minute/second combinations. Next they look at how to get the current Unix timestamp, using that to calculate day differences and working with relative time strings.

The tutorial ends with a look at the DateTime functionality also included in PHP and provides several examples of it in use for both formatted date output and calculating time differences.

On the Laravel News site there's a tutorial posted showing how to work effectively with mutable and immutable DateTime functionality in PHP. The DateTime functionality has long been bundled with the language and offers powerful tools for working with dates, improving on what the basic date function provides.

Mutable dates can be the source of confusion and unexpected bugs in your code. My goal isn’t to tell you that DateTime is evil because it’s mutable, but to consider the tradeoffs and benefits of using mutable versus immutable DateTime objects. Either approach warrants a good test suite and an awareness of how modifier methods affect your date objects.

Until recently, I wasn’t even aware that PHP offers a counterpart to the DateTime class: DateTimeImmutable. The DateTimeIummtable class works just like the DateTime class, except that it never modifies itself, but returns a new object instead. So if you know how to work with DateTime, you immediately can work with DateTimeImmutable.

The article starts by talking about mutable DateTime objects and shows examples of using the Carbon date handling package as a layer on top of PHP's DateTime handling. It includes code examples of mutable objects. It then moves on to the immutable objects, covering the differences between the two complete with code examples. The post ends with a bit more information about mutable vs immutable and links to the Chronos documentation for more information on another date handling library.

Frank de Jonge has a new post to his site covering something that always seems to be a difficult topic in development: time. In his post he suggests that date and time handling in your application is a "dependency" that could be difficult test.

When developers talk about the infrastructural boundaries or external dependencies they often talk about databases and third-party integration. They're the first thing we'll put behind an interface so we can stub them out during our tests. This gives us some control over them. It's become relatively easy to spot these dependencies because we do it frequently. They're the usual suspects.

However, some "dependencies" are much harder to spot. They even live right inside the standard library of PHP and often manage to seep through the cracks. Date/Time handling is such a thing. So what's the problem and how do we fix it?

He goes on to talk about date/time handling programming languages in general and how its variance can can cause issues that might be out of our control. He suggests that when time "gets the best of you" you should opt to be more specific in your date/time handling (the cause is usually precision). He then gets into some code examples of how to "control time" by reducing the impact that direct date/time handling could have on your application. He also includes an example of testing this handling and finishes with the idea of "consuming time as a service".

In a new post to his site Derick Rethans talks about "analemmas" and shows how to use PHP's own DateTime handling to determine the locations of the sun at different intervals (that's what an "analemma" tracks).

Last week I listened to an The Sceptics' Guide to the Universe where the word of the week was "But as I am currently starting to update the Guide to Date and Time Programming for a second edition, I was wondering whether I could create an analemma from existing PHP functions. Unfortunately, PHP only provides functionality to calculate when the Sun is at its highest point, through date_sun_info().

He includes an example of this function in use to determine the time the sun was at its zenith. While PHP by itself can't calculate the position, Derick remembered a PHP extension he wrote that could help: php-solarsystem. He includes some code using this functionality to iterate and locate the sun via its azimuth and altitude based on his choice of location (London). The result is a CSV export of data that he then drops in to gnuplot to create the graph of the analemma during that time.

Robert Basic has a quick post to his site sharing a method he uses for creating datetimes from a format with a timezone. In his examples, he makes use of the createFromFormat handling in PHP's DateTime functionality to more correctly handle processing strings with timezone offsets rather than a DateTimezone parameter.

I wouldn’t be writing this blog post if I’d read all the “fineprints” in the PHP manual. Alas, here we are.

The DateTime and DateTimeImmutable classes have a createFromFormat method. As you can probably guess from its name, it creates a datetime object from a datetime string formatted in the specified format. [...] When the format has a timezone offset though, that’s… the part I skipped in the manual.

He found that the createFromFormat handling ignores the provided timezone as the optional third parameter if there's an offset included with the date/time string to parse. No error is thrown, it just silently ignores the third parameter and sets the "timezone" value of the resulting object to an odd value.

In a new post to his site Derick Rethans talks about the new DateTime support in MongoDB and includes some PHP examples showing the changes in action.

In the past few months I have been working on adding time zone support to MongoDB's Aggregation Framework. This support brings in the timelib library that is also used in PHP and HHVM to do time zone calculations.

He then splits the rest of the post up into parts for the changes that this integration brings:

• Time Zone Support for Date Extraction Operators
• The $dateToParts Operator
• The $dateFromParts Operator
• Changes to the $dateToString Operator
• The $dateFromString Operator
• Using Date Expressions in $match

The post ends with a few notes about these changes, noting that it's currently only in the development release and "should be considered experimental" and subject to change. He then points out a few issues that will probably require updates to these features.

In a recent post to his site Ross Tuck looks at improving time objects with imprecision, basically determining the granularity you require and using that in all time operations.

When modeling important numbers, it’s considered good form to specify the precision. Whether it’s money, size or weight; you’ll typically round off to a given decimal point. Even if it’s only for user display, rounding off makes the data more predictable for manipulation and storage.

Unfortunately, we don’t often do this when handling time and it bites us in the rear.

He gives an example of a use of the DateTime handling in PHP and possible inconsistencies when working with the time portion. He offers three possible solutions: one where the time is specified correctly, making a relative modification on the object being checked and, his ultimate solution, just "throwing away" the time and not worrying about it. He then shows how to encapsulate this checking and a few other issues that can come with date/time and evaluations (like equals checks).

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.