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 Matthias Noback takes a look at unit testing your code and how it can be "dangerous" if you use mocking/doubles in the wrong way (not effective testing). Instead, he makes the recommendation to mock at architectural boundaries, specifically looking at mocking persistence and time handling.

More and more I've come to realize that I've been mocking less and less. The thing is, creating test doubles is a very dangerous activity.

[...] For example, by creating a test double for the EntityManager, we're assuming that it will work well with any objects we'll pass to it. If you've ever debugged an issue with an EntityManager, you know that this is a bad assumption. Anything may go wrong: a mistake in the mapping, missing configuration for cascading persist/delete behavior, an issue with the database credentials, availability of the database server, network connectivity, a missing or invalid database schema, etc.

He then gets into the concepts behind mocking across the "architecturally significant boundaries" and what kind of functionality this involves. He then gets into the two different examples sharing some of the basic concepts and test examples for evaluating persistence and time handling. He finishes up with a look at some of the potential consequences ("outcomes" is really a better word) of refactoring your tests and code to follow these ideas.

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

Jordi Boggiano, author and lead developer on the Composer project has posted his latest updates sharing the PHP version statistics for the first part of 2017.

It's stats o'clock! See 2014, 2015, 2016.1 and 2016.2 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last month for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He starts with the differences between now and the last time he ran the stats with a nice trends towards the PHP 7.x releases, especially PHP 7.1. He shares some graphs of the overall version distribution and a time-related graph showing changes in usage over time. Finally, he ends the post the same way as the others showing requirements of packages and how they've changed since the last update (what version a package requires).

On the SitePoint PHP blog editor Bruno Skvorc has written up an article that wonders if 9-to-5 developers can be good developers.

While picking talks for the conference he’s organizing, James Titcumb recently tweeted that well known speakers get picked over others because, among other things, they’re reliable (i.e. they don’t cancel). I would argue that “among other things” carries more weight – I believe that most conference organizers pick such talks and speakers because they like to play it safe and fear risks.

Bruno gets into some of his own opinions about conferences and speaker selections first, noting that he sees a lot of organizers "playing it safe" with topics and speakers (and the idea of "intellectual diversity"). He then talks about the 9-to-5 developers out there that haven't been exposed to a lot of these "safe" topics because they don't branch out of their corporate bubble and attend conferences. He ends the post reflecting on one of the most used excuses for not branching outside of work hours - time, it being a "precious resource" and ideas about balance.

The TutsPlus.com site has posted the next in their "Building Your Startup" series of tutorials covering the use of Yii2 to create a calendaring application. In this new part of the series they continue migrating some functionality over to use an Ajax-powered system, reducing the need for page reloads.

Last week, I delved deeper into Ajax to transform the meeting scheduling experience into a fully ajaxified model and eliminated the need for page refreshes. I got about halfway, focusing mostly on the straightforward elements.

In today's tutorial, I'll guide you through the more complex content panels that required a lot more troubleshooting, research, debugging, brainstorming, and recoding. [...] I'm also going to show you how I used Google's Chrome browser developer console to help me identify the broken areas—which can be especially difficult when working with Ajax between PHP and JavaScript. It's like light at the end of the tunnel of darkness.

The tutorial then walks through the updates needed to move over various pieces of functionality to the Ajax-driven model:

• adding meeting participants
• adding dates and times
• adding meeting places

There's also a few screenshots included of the Chrome developer console and what some of the example request/responses look like, helping you debug your own development work.

Matt Trask has put together a new post spotlighting a handy library that's widely used across the PHP ecosystem for generating UUIDs: ramsey/uuid.

Welcome to the first installment in my 2113918230981 part series, "Better know a Package!". Tonight's package: the famous/infamous Uuid package that that taught us all what Ramsey is in Scottish, Rhumsaa. Created to give PHP a library to generate Universal Unique Identifiers, this library has been a stallwort in the community. Ben Ramsey created it first under the Rhumsaa namesapce before moving it to the Ramsey namespace, saving us all from learning more Scottish then we needed to ever learn.

[...] A UUID, or Universally Unique Identifier, will generate a 128 bite unique key in different series based on the version you asked for. RFC-4122 dictates how Uuids should be generated, and recommends 4 types.

Matt then goes on to describe each of the different UUID types and provides some code examples as illustration:

• Version 1: Time and MAC addressed based Uuid
• Version 2: DCE-based
• Version 3: UUIDs based on a namespace and then it is MD5 hashed
• Version 4: Random generation (based on the output of random_bytes

He also includes examples of the UUIDs output by each method (not much difference there as the structure of the resulting UUID is all the same).

On the FreeCodeCamp Medium blog Bill Sourer shares some tips you can use to find time to become a better developer in the fast-based, sometimes crazy world of software development.

There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time!

Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important.

He breaks it down into five main tips (here's a tl;dr for those in a rush):

• You don’t need to learn every new thing in order to stay relevant.
• Writing good code takes less time than writing bad code, BUT it doesn’t feel that way.
• Working 24/7 does NOT make you a hero. Managing expectations does.
• Not all time spent “improving” code has the same ROI.
• Scheduled down time makes you more productive.

Each item on the list has a paragraph or three explaining it in a bit more detail. There's also some other interesting ideas and thoughts in the comments of the post from other readers.

On the Procore blog there's an excellent article covering their thoughts on the evolution of software applications and the different stages they go through during their development.

If you develop software long enough, you notice patterns. One pattern that isn’t talked about enough is how systems evolve over time.

The software industry is so focused on the flavor of the week that we lose perspective. Most of what is “invented” today was created decades ago. Most problems we face today were solved by someone else.

Software developers don’t have a good understanding of our own history. In the spirit of that, I present to you my take on how software tends to evolve and why.

He starts by defining a term that is used through the rest of the article, software gravity, and illustrates how it relates to development time and complexity. He then gets into describing the seven stages of software evolution as he sees them (starting with zero, naturally):

• Stage 0: Humans, Paper, and Spreadsheets
• Stage 1: Simple Script
• Stage 2: Pile Of Files
• Stage 3: The Framework
• Stage 4: Beyond The Framework
• Stage 5: Modularization
• Stage 6: Network System

For each of the points he provides an overview of what the application might be like at this stage and what levels the complexity/gravity are at. The post ends by asking about a "Stage 7" and if it even exists, suggesting that it might be an even further abstraction from previous steps.