Thursday, April 28, 2016

php and the case of the missing timezone.

Twitter is a great service for some things. Personally, I think it's very easy to allow your feed to get noisy to the point of irrelevance, but it you're careful about what you follow it's a great service.

One of the other things it's good for is simple notifications. Twitter has a varied history of allowing third-party interfacing, but they have a well documented and useful API, which has allowed things like Tweepy for the Raspberry Pi to happen.

However, it's also a third party service, which means you are reliant on someone else to hold on to your data. I don't like that, I've had services get yanked or changed underneath me without warning, so I make it a point to find something I like and then try to duplicate it locally.

Enter a program called SocialStrap. It's one of many php microblogging programs you can run on your own server. While this one does cost around $50, it offered a clean, modern view with a good mobile look, without requiring things like Flashplayer or appearing to be a WAP site. It's also popular enough to have some third-party plugins written for it. In my case, I was interested in a set of API applications someone had written in php.

In a nutshell, the API just plugs the information you provide into the SQL backend of SocialStrap, which gets dynamically refreshed when you call the website again. Nothing fancy.


I noticed that everything I posted with the API was way off regarding time. In the morning, it was off by four hours, in the afternoon, off by 16!

Four hours is, of course, the difference between EDT and UTC. That problem was easily identified. 16 hours - I wasn't sure where that was coming from.

Doing some investigation with the SQL database, I found that SocialStrap expects the time of post to be UTC, which then is calculated to be your local time when the page is called. SocialStrap also wants the time in 24-hour format, which the API was not providing. 14:00 was being passed as 02:00. 12+4 is 16. Both of my problems right there, but how to fix?

php is interesting in that you can specify a timezone locally, inside your script. So if you want to process everything UTC while your machine sits in EDT, no problem! You can place this code at the top of your script, directly below your <php? tag:


This command has a list of timezones you can operate on, and that list can be found here.

That took care of part of the problem. Now, why is it giving me 12-hour time? Turns out, php is like most other modern scripting languages - it can give you the time in an almost unlimited number of formats. Digging through the API code revealed this:

 $created_on= date("Y/m/d h:i:s ");

What's wrong with that? Well, it's a perfectly valid statement, except that the small "h" tells php you want the time in 12-hour format. Changing it to this:

 $created_on= date("Y/m/d H:i:s ");

fixes the problem. Now, the API inserts posts into SocialStrap with UTC, 24-hour formatted timestamps, and my automatic posts are no longer 16 hours off from their actual post dates! What do I get for my trouble? A list of machine outputs and things hosted locally on my own server.

Kestralbot, the confused bird who can't even spell his own name, chirps on a regular basis, no third-party required. (I passed the bugfixes on to the author who was delighted that someone was using his code and had taken the time to improve it.)