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.

The Full Stack Radio podcast, with host Adam Wathan, has posted their latest episode with guest David Hemphill - Episode #62: Timezones, Webhook Security, and UI Decisions.

In this episode, David talks about adding timezone support to Crondog, and Adam wrestles with some decisions about dealing with failed webhooks in KiteTail.

We also talk a lot about different strategies for securing webhooks, and what we're looking forward to at MicroConf.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter to get the latest announcements when new shows are released.

The TutsPlus.com site continues their "Building Your Startup" series of tutorials with the latest in the series covering automatic timezone detection based on the user's local time.

For the alpha release of Meeting Planner, I provided people the opportunity to change their time zone in user settings. However, for anyone outside of the western United States, they may have been wondering why their calendar appointments were at the wrong times. You have to know to look for the settings page.

As I approach the beta, I realized I needed to fix this as soon as possible. So I began to reflect on how best to resolve this. In today's episode, I'm going to walk you through my approach to automatic time-zone detection and how I integrated it into the user experience.

The tutorial starts off with a look at the current state of timezone detection, linking to two options that do mostly the same thing. Eventually, however, he decided on the jsTimezoneDetect library as it fit best with the needs of the application. He covers some of the thoughts that went into designing the user experience and the code required to integrate the Javascript library with his Yii2-based application. He ends the tutorial with a few additional considerations worth keeping in mind including timezone representation in ical exports and virtual meetings.

Evert Pot has a new post sharing some of the changes in DateTime handling that he's updated in the latest release in the PHP 5.5.x series.

PHP 5.5.10 got released a few weeks ago, and among other things, it added some new functionality related to timezone handling. In short, [subtracting from UTC] now works. Normally this would not be recommended, as you really should specify timezones based on their geographical location. This information is not always available though, so it's a welcome new feature.

Other changes include the removal of the automatic translation from "UTC" to "GMT" as well as errors being thrown when one of the "odd" timezones are used (he provides the list). Additionally, an update around timezone "guessing" has been added and the fallback that was in place has been removed.

On the Websanova.com site there's a recent post about doing timezones the right way when working with them in PHP and storing them in your (MySQL) database.

Timezones are actually a very trivial concept but they seem to be overlooked and over complicated. [...] Rather than storing a timezone with each date it’s better to just accept a standard time to store all your dates with, thus doing the conversion to that standard time before storing the value in the database. It doesn’t really matter what time we store it as, but it’s generally a good idea to just use UTC+00:00.

They talk a little about what the UTC timezone is for those that may not know and show how to set it as the default timezone for your PHP application (with date_default_timezone_set or updating your php.ini). They also include the MySQL configuration option to set its default timezone and and example SELECT statement for extracting the data back out.

In this new post to his site, Derick Rethans shows an instance of "GMT being tricky" when it comes to "UTC" versus "GMT" output from PHP's DateTime object.

Earlier today, on twitter, @skoop asked: "dear #lazyweb, when I use DateTimeZone('GMT'), why does format('e') output UTC?" [...] As you can see [the example with a format of "e" on a DateTimeZone('GMT')] has UTC and not GMT as you might expect.

Derick mentions that sometimes, systems require "GMT" instead of "UTC" in the output they're given. To work around this issue, he shows how to add a "type 2" timezone to the DateTime object by including it when you initialize the object (code samples included). Using alternative methods, you can add these "type 2" timezones in three ways - an offset in the initial string, using the abbreviation (like "EST" or "PST") and specifying the long version of the timezone (like "America/Montreal").

In a new post to Stephen Colebourne's blog today, there's some bad news for developers of software and OSes in general - the timezone database that most software uses is down due to a copyright struggle with a company named Astrolabe, Inc.. How does this relate to PHP? It's the same database the language uses to define its timezones as a part of the DateTime functionality.

The time-zone database (sometimes referred to as the Olson database) is the computing world's principle source of time-zone data. It is embedded in every Unix and Java for starters, and will be used by many websites and probably by your iPhone. You may know it via the IDs, such as "Europe/London" or "America/New_York". But, perhaps you're thinking that time-zones don't change? Well that may be true for America and the EU right now, but certainly isn't for the rest of the world.

Astrolabe claims that the database is a part of the work on their "ACS Atlas" product and the contents of it belong to them.

The impact of this is severe for anyone that uses it - whether via Java, Unix or some other means. This really is the key tool used by everyone to tell the right time globally. We all owe a debt of gratitude to the database maintainers who have worked on this for many, many years at zero cost to the industry and for zero financial gain.

Stephen puts out a call to some of the larger technology leaders/companies to help resolve this situation and/or provide a resource where this information can once again be accessed freely.

Christian Schaefer has a recent post pointing out a common frustration among developers of applications with NoSQL backends, specifically with Doctrine, MongoDB and PHP DateTime objects - timezone conflicts.

I really like Doctrines way of dealing with dates and times. Instead of passing timestamps around or strings with ISO date format it simply makes use of the PHP native type DateTime which provides all you really need to work with. PHPs interface to MongoDB however comes with its own MongoDate type which provides hardly any functionality compared to DateTime and it’s not compatible with it. So what’s the difference?

In some of the comments to the post, readers mention that the problem is bigger than just the tools used to work with the database, it's that databases usually don't care about timezones when working with date/time. There's also an interesting mention further down about the timezone support MongoDB does have and an example snippet ofo code that uses the support.

James Cohen has a new post to his blog today looking at some of the built-in functionality that PHP has to work with dates and times including simple things like strtotime and the DateTime feature.

A lot of people ask questions relating to date and time in PHP. Here are some answers to the most commonly asked questions and common mistakes.

He covers the differences between working with dates in strtotime, worrying about timezone settings and compares the strtotime/DateTime methods for formatting and returning dates, modifying dates, converting between timezones as well as finding the difference between two timezones.

In a new post to the SitePoint PHP blog today Craig Buckler looks at a method for synchronizing your time between your PHP application and it's MySQL backend to make date handling a bit easier - no messy code-based timezone changes needed.

Many developers solve the problem by shifting all date/time responsibility to PHP. They may also convert dates to Unix timestamp integers for simpler handling, although you should be wary of the Y2K38 Bug.

They show a handy tip so you won't have to worry quite so much that relies on setting a "TIMEZONE" constant you can use to set the default timezone and a "time_zone" offset that can be used each time you make the connection to your database (or, alternatively, in a cron that keeps things up to date without interfering with performance).