Technical insights and software architecture

Deep dives into PHP development, Horde Framework evolution and practical software engineering. Focused on real-world solutions for complex technical challenges. “Always close to the source”.

Core Topics

PHP, Horde Framework, authentication systems, composer workflows and modern development practices.

Long-form Analysis

Comprehensive technical articles exploring architectural decisions, migration strategies and lessons learned from real projects.

Code & Community

Open source contributions, framework development and sharing knowledge with the PHP developer community.

Time, it needs time

As I am writing this, bug reports from users are coming in on last night’s updates to Turba Addressbook. In Turba we first rolled out our new way of date handling and upgrading existing user-selected date formats in backends. The initial results were … mixed.

Horde comes from the strftime era, a way of formatting dates which has widely been deprecated since. We are moving towards the ICU standard as implemented in IntlDateFormatter.

But let’s take one step back. The issue is simple to describe: All around there are existing installations which have default or mandated date format strings set by their admins in strftime format. On top of that, users have customized date format strings in strftime format in their SQL and LDAP backends. We cannot simply break that. But we have to move on. We used to support strftime format through a compatibility library but it’s not the way forward.

So we currently convert-on-load if a format string looks like strftime and further down the road we work with that format. But all the stack either defaults to strftime format or the DateTime::format way of formatting dates (which isn’t international at all and quite lacking).

So we started bottom up, added new ways of formatting to the Horde_Date library which we already use widely. But we kept compatibility – we don’t want situations which force upgrades in many places at once. We want a smooth transition.

So every library using Horde_Date::format needs to tell it to use the new way of presenting that format. In comes Horde_Form.

Horde_Form defaults to formatting with strftime. You guessed it. It’s so widely used we don’t want to break it. It’s breaking more often than we want already. Different story, different day. We have a very dedicated team member scratching head and making Horde_Form break less, preparing transition to an all new, more robust iteration of the same thing while keeping BC. (Well, mostly. Sometimes we gotta break if we can’t help it. Better break in pre-release than endure pain after release.) I’m glad we have him.

So next we need applications to opt-in to Horde_Form using the new formatting standard because by default it will assume we have the old one.

It’s the final layern. Turba will be the first application to test this concept and then we will migrate more applications and finally the base application. Ain’t no use in complaining. Let’s hope the transition goes halfway smooth. We added a lot of new tests along the way. Yet end user testers found some issues already. I’m glad we have them.

turba beta1: Formatting issues with date fields · Issue #28 · horde/turba


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *