Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'd have to recommend storing all your times in UTC, then also storing the user's timezone offset. This allows for maximum flexibility, and some decent separation between actual data (UTC time) and display logic (UTC +/- Offset).</p> <p>For storage, no matter how many times I try RDBMS specific time fields, unix timestamps in an int field always offer the best flexibility and portability.</p> <p>You could store the user's timezone offset in seconds to make the process even simpler. So EST (-5) would become -18 000</p> <p>Then, for displaying time -/+ user's offset, simple second maths will work just fine:</p> <pre><code>$now = time(); $userTime = $now + $user-&gt;getTimezoneOffset(); </code></pre> <p>This'll work fine because adding a negative number is just like subtracting a positive one.</p> <p>Edit:</p> <p>You will be able to format the user's timestamp using PHP's standard <em>gmdate()</em> function. Just pass the calculated timestamp as the function's second parameter. See <a href="http://ca2.php.net/manual/en/function.gmdate.php" rel="nofollow noreferrer">http://ca2.php.net/manual/en/function.gmdate.php</a> </p> <p>Whoops... date() is current locale aware. should use gmdate() instead.</p> <p>There is of course, one totally different approach which may be better: Store a textual representation of the User's timezone which is compatible with PHP's date_default_timezone_set() . Then, on each request, if you have an authenticated user, you can set timezone, and all date functions will obey it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload