News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

[SMF 2.0b3.1] Set overall time offset %Z variable misleading or borken

Started by Deprecated, August 23, 2008, 07:41:09 PM

Previous topic - Next topic

Deprecated

I came across this answering a 2.0 support question in this topic: Odd time zone problem

Admin -> Configuration -> Features and Options -> Options -> Overall time offset

Allows you to configure the forum's time display shown in upper right corner of pages, default string = "%B %d, %Y, %I:%M %p" ... One of the options is "%Z - time zone or name or abbreviation" My server and the complaining party's server are both on the East Coast US. When either of us configures in the %Z variable it lists GMT+5 after the displayed time. I've verified that my server is on ET by running a script echo(date_default_timezone_get()); which tells me my server time is America/New_York. The ET zone is offset from GMT by -5 hours (or -4 hours when dalylight savings time is in effect). I'm not saying that the designation GMT+5 is incorrect, it may be either right or wrong, but the problem is that it's useless.

Okay that's the facts now here's the problem: No matter what you set the Overall time offset to, the string displayed by %Z doesn't change. That means that when you change the offset the number displayed changes but the %Z doesn't change, i.e. on my setup it just stays at GMT+5. But wait! It gets worse! When a member programs a time offset in their profile, that doesn't change the GMT+5 display either!

Here's my recommended solution: Just delete the %Z functionality. Take %Z off the help file listing, and optionally filter %Z out of the string. Or you can spend a bunch of time and calculate what the correct displays and take into account both server offset and member profile offset.

Deprecated

Another thing I just realized, even though my host says they are America/New_York, I have to enter a time offset of 1 to get my SMF to read the correct time for New York. The party in the other post observed the exact same thing, have to set 1 hour offset to get his to read correctly.

We should compare with some different hosts to see if this is a hosting problem or a SMF problem. I have only one place to experiment on.

Deprecated

I have another observation. My server logs are correct for EDT, i.e. GMT-4. But I have to set my SMF for an offset of 1 to get correct EDT listed on SMF when viewed as guest.

SMF appears to be 1 hour off in its calculations. Or at least the discrepancy needs to be accounted for.

Thantos

As far as the time zones go it is just passed to strftime.  PHP is going to print the time zone of the server, not of the client.  While the TZ might be useless there is no bug.

Quote from: Deprecated on August 23, 2008, 07:45:47 PM
Another thing I just realized, even though my host says they are America/New_York, I have to enter a time offset of 1 to get my SMF to read the correct time for New York. The party in the other post observed the exact same thing, have to set 1 hour offset to get his to read correctly.

We should compare with some different hosts to see if this is a hosting problem or a SMF problem. I have only one place to experiment on.
Sounds like a daylight savings time issue.  Not much SMF can do about it (at least not without a lot of hassle [especially considering how the dates have changed in the last few years])


Deprecated

Quote from: Thantos on August 23, 2008, 09:12:35 PM
As far as the time zones go it is just passed to strftime.  PHP is going to print the time zone of the server, not of the client.  While the TZ might be useless there is no bug.

As the developer it is your responsibility to make sure that features behave in an intelligent manner for your users. I think I've already made my case that in this feature it is not. You seem to be blaming the incorrect response of SMF on the platform rather than accepting that you must make it work for your users.

And did you even look at the code, make experiments, to ensure that this feature is working properly? Or is your response just a policy statement?

Deprecated

Quote from: Deprecated on August 23, 2008, 08:39:02 PM
I have another observation. My server logs are correct for EDT, i.e. GMT-4. But I have to set my SMF for an offset of 1 to get correct EDT listed on SMF when viewed as guest.

SMF appears to be 1 hour off in its calculations. Or at least the discrepancy needs to be accounted for.

I've written the following which I intended to reply to another thread discussing this topic, but I decided it is more appropriate to post it here in my bug report:




My site runs PHP 5.2.6. I have now observed the exact same one hour offset on three different hosting services, two of mine on different hosts and the third a friend's SMF. All show a one hour offset from the server time when forum offset and personal offset are both zero. This problem is best analyzed by not being logged in to SMF, so that you are looking at only the SMF time and not any personal configuration of offset.

I'm convinced there is a flaw in SMF's logic on how to calculate the correct time. I have been intending to get back to this bug report and dig into SMF's code and gain an understanding of how that works so that I can form an opinion on whether the code is right. Analyzing it from the outside there is an hour that is not accounted for. All three hosting services require SMF to adjust the server time by one hour to show the correct server time for guests. I define server time as the time shown in server logs. Mine are all using EDT.

That brings up another interesting point. My hosting package is using EDT? What the heck is that? Do they set it forwards and back according to daylight savings rules? That is totally unacceptable to me, although of course I have a fat chance of changing that. I cannot comprehend why they don't use UTC for all servers around the world. What is this regionalism thing with them? I could figure my own host (1&1) might be an oddball, but all three servers that I have access to are located in and using US timezones, adjusted for daylight savings time. Daylight savings? That's so quaint and has no place in international venue like anything having to do with the Internet.

The server should use an absolute time standard, and it should be up to SMF to handle any localizations. I've been following another modification (forgot the name) which adds full internationalization to SMF and allows members to adjust to their own timezone including oddities such as daylight savings. What is going to happen when some server jock throws the switch and shifts the whole server one hour? That is just &$#@*^$%@ insane!!!

Anyway I think SMF has a bug and I'm either going to find it or convince myself that I'm wrong after I've dug into the code and understand it. This is also complicated by needing an understanding of the PHP routines that SMF interfaces to. I haven't forgotten this topic and I will eventually get to the bottom of it.

SpectroPro

Quote from: Thantos on August 23, 2008, 09:12:35 PM
As far as the time zones go it is just passed to strftime.  PHP is going to print the time zone of the server, not of the client.  While the TZ might be useless there is no bug.

Quote from: Deprecated on August 23, 2008, 07:45:47 PM
Another thing I just realized, even though my host says they are America/New_York, I have to enter a time offset of 1 to get my SMF to read the correct time for New York. The party in the other post observed the exact same thing, have to set 1 hour offset to get his to read correctly.

We should compare with some different hosts to see if this is a hosting problem or a SMF problem. I have only one place to experiment on.
Sounds like a daylight savings time issue.  Not much SMF can do about it (at least not without a lot of hassle [especially considering how the dates have changed in the last few years])

I just installed this version of SMF on a server located in Milwaukee, WI.  That is Central time.  THE same problem occurred.  So now I have 2 hosts with the exact same problem  I don't think so.  NO MATTER where this has been hosted, and there are at least 3 seperate hosting services now, 2 in eastern and one in central..and they all show the same thing.  +5 GMT. 

I installed 1.1.5 on my current host.  It shows the correct time zone GMT.  As I have stated elsewhere, I have several apps that I run on my host.  They all show the correct time.  The ONLY incorrect time is shown via SMF 2xxx  (yes, I am too lazy to memorize what the latest version is, but it's what I have)  hehe

Stats:  SMF v. 2b4  -  Mambo v4.65  -  Bridge v2.0b1

http://www.therealityrocks.com    http://forum.therealityrocks.com/trr
- Greg

Deprecated

I'm convinced there is a missing hour for SMF. I'm also convinced that the %Z thing is borken and should not be used. I predict that will never work right unless somebody throws massive code at it.

I still intend to get to the bottom of this problem, but other higher priority projects have taken up my time.

GJSchaller

I'm witnessing the exact same problem as Depreciated, but in SMF 1.1.9 - Server is set to EDT, time is off by one hour.

Now, here's the odd part - A) I vaguely remember this as an issue before, but can't find the fix I used when I google it up (although that could just be me).  B) I have a second install on the same server, that is NOT having this issue.  Both installs of SMF have an overall offset of 0, and both are on the same server (running PHP 5.2.6).  The only difference between the two installs is that the one with the time issue was recently re-built by removing all Mods, uploading all files again, and re-applying all mods due to some messiness when I tried to apply a mod recently. So, the forum with the issue is a fresh install of the 1.1.9 code base, with new mods applied, where the correct one is an older install patched up to 1.1.9.
Geoffrey J. Schaller
Knight Realms - Technical Officer
http://www.knightrealms.com/

Advertisement: