Relative date issue
Submitted bfarber, Jan 11 2012 10:09 AM | Last updated Sep 18 2012 04:49 AM
The code in class_localization to determine "today" and "yesterday" is not taking the time zone offset into account. This issue was noticed in IP.Content, but appears to stem from IP.Board's getDate function, so logging here.
Scenario: the forum server is in GMT-6, the default guest time zone is GMT-6 and the user time zone is GMT-6. A calendar event was created for 1/10/2012 at 7:30PM (GMT-6). It shows correctly in the calendar (which does not use getDate).
Prior to 6PM for the user, it displays as "Today 7:30PM" (which is correct). After 6PM it shows "Yesterday 7:30PM" which is obviously incorrect.
I should note that Content is actually setting class_localization->offset to 0 (because it doesn't want class_localization changing the date sent to it based on the user's time zone - that's already handled by the calendar code). This is a change in how it normally works of course, but shouldn't actually be a problem. As noted, it shows "today 7:30PM" until 6 PM, and then "Yesterday 7:30PM" after 6, which is clearly wrong.
Might be because we use gmstrftime() but the server is actually in GMT-6, applying a "hidden" offset effectively.
Scenario: the forum server is in GMT-6, the default guest time zone is GMT-6 and the user time zone is GMT-6. A calendar event was created for 1/10/2012 at 7:30PM (GMT-6). It shows correctly in the calendar (which does not use getDate).
Prior to 6PM for the user, it displays as "Today 7:30PM" (which is correct). After 6PM it shows "Yesterday 7:30PM" which is obviously incorrect.
I should note that Content is actually setting class_localization->offset to 0 (because it doesn't want class_localization changing the date sent to it based on the user's time zone - that's already handled by the calendar code). This is a change in how it normally works of course, but shouldn't actually be a problem. As noted, it shows "today 7:30PM" until 6 PM, and then "Yesterday 7:30PM" after 6, which is clearly wrong.
Might be because we use gmstrftime() but the server is actually in GMT-6, applying a "hidden" offset effectively.
| Status: | Cannot Reproduce |
| Version: | 0 |
| Fixed In: | 0 |
15 Comments
<?php require_once( './initdata.php' );/*noLibHook*/ require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );/*noLibHook*/ ipsRegistry::init(); foreach ( array( -10, -5, 0, 5, 10 ) as $offset ) { ipsRegistry::member()->setProperty( 'time_offset', $offset ); ipsRegistry::getClass('class_localization')->offset = ipsRegistry::getClass('class_localization')->getTimeOffset(); echo "<strong>GMT" . ( $offset >= 0 ? "+{$offset}" : $offset ) . "</strong><br />"; echo 'Time Now: ' . ipsRegistry::getClass('class_localization')->getDate( time() , 'LONG', FALSE ) . '<br />'; echo '5 hours ago: ' . ipsRegistry::getClass('class_localization')->getDate( time() - ( 60 * 60 * 5 ), 'LONG', FALSE ) . '<br />'; echo '10 hours ago: ' . ipsRegistry::getClass('class_localization')->getDate( time() - ( 60 * 60 * 10 ), 'LONG', FALSE ) . '<br />'; echo '<br />'; }Produces:
Which looks fine to me... what am I missing?
Keep your same offsets, but try when GMT is shortly after 12:00 AM.
Here's a test case I just created that I *think* is showing a similar symptom, so it probably has the same root cause.
Time now (real) in GMT-5: 1/19/2012 10:21 AM
<?php require_once( './initdata.php' );/*noLibHook*/ require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );/*noLibHook*/ ipsRegistry::init(); $time = strtotime( "2012-01-20 00:30:00" ); foreach ( array( -10, -5, 0, 5, 10 ) as $offset ) { $newtime = $time + ( $offset * 3600 ); ipsRegistry::getClass('class_localization')->offset = 0; echo "<strong>GMT" . ( $offset >= 0 ? "+{$offset}" : $offset ) . "</strong><br />"; echo 'Event time: ' . ipsRegistry::getClass('class_localization')->getDate( $newtime, 'LONG' ) . '<br />'; echo '<br />'; }This simulates an event for (in my time zone) 1/19/20012 7:30PM (because calendar stores dates as GMT across the board). When I run this locally, here's the result
Note that GMT-5 IS correct, but it says "19 January 2012" instead of "Today" even though relative dates are on. This is slightly different from what I was describing, but like I said, I think it points to the same underlying issue (the code to make the dates thinks it is tomorrow because that's what the timestamp says and we're telling it not to apply any internal offset, but in reality, the date is for today and the relative date should reflect that).
Thanks.
Now that I've fixed the query to make sure the block still holds events from 'today' till the end of the day, i'm seeing the parse date issue. I would venture a guess that the ONLY way you will be able to reproduce this is if the dates are different between your timezone and GMT... So you'll either need to work on a server where you can fudge the time, or test it after 6 PM CST.
[attachment=38922:parse date.png]
<div class='maintitle'>Upcoming Events</div> <div class='ipsBox table_wrap'> <div class='ipsBox_container'> <ul class='hfeed'> <if test="is_array( $records ) && count( $records )"> {parse striping="feed_striping" classes="row1,row2 altrow"} <table class='ipb_table'> <foreach loop="$records as $r"> <tr><td class='row2'> <li class='hentry'> <a href='{$r['url']}' rel='bookmark' title='{$r['title']}' <if test="($r['date'] + 3600 ) < time()"><else /><if test="($r['date'] ) < ( time() + 21600)">style="color: #e83c0c"<else /><if test="($r['date'] + $this->registry->class_localization->getTimeOffset() ) < ( time() + 86400)">style="color: #e8c30c"</if></if></if>>{$r['title']}</a> <br /><span class='date'><abbr class="published">{parse date="$r['date']" format="short"}</abbr></span> <if test="$r['event_rsvp'] == 1 && $this->memberData['member_id'] != 0"> <span> - <a href='{$r['url']}page___rsvp__1'>RSVP</a></span> </if> </li> </tr></td> </foreach> </table> </if> </ul> </div> </div>{parse date="$r['date']" format="short" relative="true"}I believe Brandon recently fixed something related to this in IP.Calendar based on your findings. Can you still reproduce this issue after those changes?Nvm, talked this over with Brandon. I'll confirm for now but it's going to be hard to reproduce properly.
I dug through the template plugin code for the parse date briefly and the code 'appears' to be fine, it's almost like it isn't actually applying an offset when $time_today and $time_yesterday are being created.
I'll be able to reproduce it this evening and see if I can isolate anything...
Signed IN (correct)
[attachment=39057:signed_in.png]
Signed OUT (wrong)
[attachment=39058:signed_out.png]
The fun thing... Both my account specific timezone and the board default are the same... (-6)
[attachment=39118:cal_feed.png]
Updating Status to: Cannot Reproduce
Updating Version to: 0
I think the bets thing to do at this point if you're still experiencing the issue is to open a support request so we can take a look - even adjusting my server's time manually, I can't reproduce this issue.