Plugin Author
room34
(@room34)
Hi… due to persistent issues with PHP and WordPress time functions trying to interpret and calculate time zone information, rather than doing pure formatting of the time text string, I had to add my own time formatting function to the plugin. I tried to account for the most common time display format options (34 in all), but I had not anticipated the use of “T”. When the requested format isn’t one of the one I’ve loaded in, it falls back to “H:i” as a default.
I will add this option. This is a very simple change so I should have an update available later today.
Plugin Author
room34
(@room34)
Ah, well… on second thought, this is not a very simple change. Displaying the time zone identifier, e.g. “America/Chicago”, would be easy. But once we get into these abbreviations it brings Daylight Saving Time into the equation and suddenly we do need the complicated date functions that were causing display issues.
I can very easily strip out the timezone abbreviation, so you’d at least get this falling back to the equivalent of g:i a instead of H:i. But anything that would actually display the timezone abbreviation is going to get fairly complicated, and won’t be something I can immediately resolve.
I’m going to guess that ultimately you do want the timezone abbreviation, so I’ll continue to look into this, but I’m also guessing that g:i a would be preferable to H:i in the meantime.
Thread Starter
setnes
(@setnes)
Wow. Thanks for the fast reply and awesome plugin. I have to admit I just tried the plugin for the first time this weekend, and this seemed like a bug worth logging. I was scratching my head for a bit testing it. Maybe the fix is just an update to the documentation to mention T isn’t valid in the time format. <shrug> 🙂
I’d certainly use it if it was there, but I can just as easily mention the timezone outside of the calendar embed.
Looks like we’re both in MN. Awesome.
Plugin Author
room34
(@room34)
I wish this wasn’t such a thorny issue. The reason it’s a problem is that the ICS Parser library is already doing timezone adjustments and it outputs a time string, separated from the date, that is already adjusted for the designated timezone. It accepts a time format, but given the way I’m using the library, I need the flexibility to make subsequent changes to that time format, after it’s already parsed the time out of the date.
All of that is fine as long as we’re strictly dealing with a time string. But like I said, mixing the timezone into it suddenly makes it essential to know the date again, because the timezone abbreviation changes depending on whether it’s DST or not. (And PHP doesn’t particularly like using these abbreviations anyway, but we humans, at least in the US, prefer to say “CST” or “CDT” rather than “America/Chicago”!)
Anyway… I get the value of having the timezone code in there, especially if you have users of the site who may be in different timezones. I just need to figure out the best way to add this capability in without unraveling the situation. (It took several weeks of troubleshooting last year to finally arrive at the current setup.)
Version 6.4.2.1 should be available now. The change I made in this is to strip out any time format characters like “T” that the function doesn’t yet support, so it gets to a time display that’s at least closer to what you want than the default H:i. I’m hopeful that’s an adequate workaround in the short term.
Yes, MN! 😀
