You may not have noticed there is an event countdown widget1 in my sidebar. Since no one has complained, I gather that no one is particularly upset that I countdown to a few select events and birthdays. Really, it’s a reminder to me that it’s coming soon because I do tend to forget things.
Yesterday, I discovered a small bug in the display of the events. I’m not sure if it has always been there and I’m blind or what, needless to say, I live in GMT-5 time zone give or take a little daylight savings time, it’s lovely here. The weather is ever changing, there are interesting birds and animals. However, the code as written doesn’t address possible time zone issues. The code assumes that the host computer is in the same time zone as the event, which is not always accurate. In an ideal world the plug-in/widget would ask me to input my desired time zone and adjust accordingly, someday I may sit down and “fix” it so that it does inquire. In my case, the server hosting this application lives in California, GMT-8 give or take a DST. What does it mean? My events calendar is about 3 hours off when it displays an event. For example, it’s midnight in GMT-5 and an event occurs at 8:00AM. As the code is written, the event is is not 8 hours away, it’s 12 hours away. In another example, an event that happened 2 hours ago is listed as one hour in the future with the code as written.
I don’t write PHP from scratch, I just read it, usually understand it and then alter it to suit my needs. But this time, I really just wanted a quick fix. This particular code was written in PHP and WordPress, so rather than trace the code from top to bottom across two files, I chose the one file I knew I needed to change and went to work. I changed random and not so random numbers and hoped that I would find it while refreshing the events list. Chaos ensued. After spending too much time, I gave in and read the code across the two files as well as comparing it to the two web pages that are produced from those files. One file is the admin interface page where all events are entered into the php database and stored as variables in the table. The other file waits to be called by a widget or page, and then pulls data out of the database, applies code to it, and displays it. All I have to say for my efforts is, “DUH!”
I had already determined that the problem existed because the of host server being in a different time zone and hoped to alter the script to tell the host server to pretend it was in my time zone. That didn’t work so much, so I read about what the different time statements were. I spent some time at PHP-Date.com and PHP.net reading about various date/time functions like current_time(), date_default_timezone_set(), date_default_timezone_get(), gmmktime(), strtotime() and a few more. The solution turned out to be very simple once I read the code and looked up what each command did. In my defense, there are nine variables but between the two files, the order is constantly rearranged so I had mixed up four of the variables, thinking they held values they didn’t hold. I discovered that current_time() was a WordPress function and MYSQL function. The actual line I tried to alter was current_time(timestamp, $gmt = 1), the however, I don’t know how variable for $gmt is used by WordPress nor what the possible values are beyond 0 and 1. I tried to alter it up through 10 and didn’t find the correct value, I added single quote/apostrophe around timestamp, I tried using mysql instead but that seemed to break it the most. Dates were displayed as seconds, rather than years, months, weeks, hours, minutes, and seconds. Why on earth would that happen? Well, Unix/Linux uses a time system based on the Gregorian calendar and midnight on January 1, 1970, also referred to as Unix Epoch. All dates/times are expressed as seconds before (negative values) or after (positive values) that date. Fun factoid: The 24 hours (a.k.a. 86400 seconds) representing August 5, 2008 are 1217919600 through 1218005940. The previous timestamps are generated using the php command strtotime() because I desperately need to something to show for the last 24 hours. Should you like to experiment with this, I recommend using using your favorite search engine and looking up the terms “unix time” or “POSIX time” along with the word converter. Please be aware that based on the command used to call the timestamp, results will vary so you may not get the same result across several different converters. I didn’t count them all, but there didn’t seem to be a shortage of unique commands to call time for various purposes, such is the nature of UNIX/Linux. One of the reasons for the difference is a problem calculating leap seconds. I’ll spare you the details.
As I just mentioned, strtotime() was a php function. While searching, I found that the php-date.com page had an interactive strtotime() box, strtotime() was used several places in the timestamp section. I could display the current GMT time, then practice using different commands to alter the displayed time. After reading that, I wondered why both strtotime() and current_time() were used. So I changed current_time() to strtotime(’+ 3 hours’) because I knew it would display the correct time based on experiments at php-date.com, at least until DST ends. Solving it this way seems crazy because somewhere in California the current time is converted from GMT to GMT-8 and I basicall changed it to GMT-8+3. Some day I’ll learn how to use the time zone things and just use GMT-5, but all it did today was break the plug-in, so I’ll leave it for now.
1 A widget is a piece of code inserted into a spot on the sidebar to perform a function. There are many widgets that have been in my side bar including a search bar, the answer to why this site is orange for August 2008, a random image from my photo gallery, and Now Reading (a list of books).
Tags: current_time(), dday, Linux, plug-in, plugin, strtotime(), time zone, timestamp, UNIX, widget, WordPress