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 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.

In a new post to his site Christoph Rumpel lists out his top three features of Laravel 5.6 that he enjoys and finds the most useful.

Yesterday Taylor Otwell released Laravel 5.6 right before the Laracon Online conference. We had a little conference party here in Vienna and a great time watching all the talks together. In one of them Taylor walked us through the new Laravel features and I want to point out my top 3 of them.

For each of his top three he provides some code examples and screenshots where appropriate:

• the addition of the Collision package
• dynamic rate limiting on route definitions
• Eloquent date casting (enhancing the "casts" functionality already present from v5.5)

For more information on the other new features that v5.6 include, check out this series of posts from Laravel News.

Jeff Madsen has a post on his Medium blog sharing some of his thoughts about immutable DateTime types, what the difference is between mutable and immutable and "why you should care".

I’m going to show you the difference between the two using two popular Php DateTime libraries? - Carbon and Chronos, and then demonstrate the danger of using the mutable one of those.

You have probably used Carbon? - ?it is a wonderful library put together by Brian Nesbitt that takes all the pain out of working with dates. It has got one “short-coming”, if you will?- ?it is built on top of the DateTime object.

He gives an example of why this is a problem with Carbon (mutable) and how it's handled differently in Chronos (immutable). He makes the point that, unless your date values are immutable, you don't have any idea of they've changed elsewhere in the processing. He gives a more real-world example of working with immutable objects with a "user" model class and the "name" properties attached to it.

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).

On the SitePoint PHP blog Younes Rafie has continued his series about the PHP "Intl" extension for use in internationalizing an application. in this second part of the series he moves away from just strings and looks at using it for currencies and numbers.

The first part of this series was an introduction of the PHP Intl extension and of how to localize your application’s messages. In this part, we’re going to learn about localizing numbers, dates, calendars, and similar complex data.

The post is broken down into a few different sections, each with their own examples:

• Localizing Decimals
• Localizing Currencies
• Timezones
• Calendars

The "Intl" extension makes these operations relatively simple with plenty of built-in objects and methods to help with the translations between the formats. You can find out more about this extension in the PHP manual.

On the SitePoint PHP blog there's a tutorial that's been posted spotlightling a PHP library that can make working with dates and times simpler: Carbon . In this new tutorial they walk you through what the library has to offer and plenty of examples of it in use.

Carbon is a small library for date and time manipulation in PHP. It relies on and extends the core DateTime class, adding helpful methods for a significantly saner experience.

In this article, we’ll take a look at some basic usage examples, and then use it in a real project.

They start with the installation (via Composer) and a few examples of it in use, determining if a given date string is a weekend, in a leap year, etc. They also talk about localization support and working with time intervals. He then gets into the more real-world part of the example, updating the Diffbot client to optionally support Carbon for its date/time handling. He starts with some tests to define how he wants the handling to work and how to use it to parse the date returned from the DiffBot API.

In his latest post Rob Allen shows a way you can override the default Twig date filter with your own custom Date extension handling.

In one project that I'm working on, I'm using Twig and needed to format a date received from an API. The date string received is of the style "YYYYMMDD", however date produced an unexpected output. [...] This surprised me. Then I thought about it some more and realised that the date filter is treating my date string as a unix timestamp. I investigated and discovered the problem in twig_date_converter.

He includes some example code you'll need to create the custom renderer. As part of the internals of how Twig formats the date currently is internal and can't be changed, he opted to override the extension itself. As a result, the call to the filter is exactly the same as before, the output results are just formatted more correctly.

In a new post to his site Ben Ramsey talks about why dates are hard and can be frustrating to work with sometimes. It revolves around an issue he recently found with calculating a time for a UUID and days of the week.

No, I’m not talking about a meeting with a lover or potential lover. While those can be stressful, the calendar math used to determine the precise date and time on which such a meeting might occur is infinitely more difficult to perform. To software programmers, this isn’t news, but I recently encountered an issue when calculating the time for an RFC 4122 UUID that had me questioning the accuracy of our modern, accepted calendars, especially with regard to the days of the week on which our dates fall.

In his work on his UUID library, he came across a the bug because of some failing unit tests. It was only happening in certain versions of PHP and upon further investigation found the issue to be a wrong day of the week from a date in 1582 (the correct value being Sunday). As it turned out, the date in question was actually a Saturday and his local environment was reporting bad results. The problem was with a revision made to the Gregorian calendar, removing 10 days causing a difference between the Gregorian and Great Britain versions of 1582.

On NetTuts.com today there's a new tutorial they've posted showing how to use PHP's DateTime functionality in a more OOP kind of way. The DateTime extension lets you work both ways - procedural and OOP, with only slightly different syntax changes between them.

The Date/Time PHP extension is a set of classes that allow you to work with almost all of the date and time related tasks. It’s been available since the release of PHP 5.2 and the extension introduced several new classes.

The tutorial first shows you some of the differences between just working with something like date and DateTime. From there they get into a bit more complicated things like:

• Modifying dates/times
• Working with multiple dates
• Working with timezones
• Using DatePeriods
• Extending the current functionality

There's also two more "real world" usage scenarios included - defaulting to using UTC times and using the DateInterval to handle subscription payment logic.