Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you only need to display times in the web interface:</p> <ul> <li>calculate time on the client as seconds (Unix time) using Date.getTime()/1000; respectively Date.setTime(utc_seconds*1000); note that Javascript uses milliseconds</li> <li>transmit all times between the client and the server as seconds (Unix time)</li> <li>store time as UTC timestamps (chances are that your backend supports conversion to a UTC timestamp)</li> </ul> <p>If you need to do other stuff on the server with human readable time (e.g. send email that includes a meeting time):</p> <ul> <li>capture the timezone in the client (e.g. using <a href="https://bitbucket.org/pellepim/jstimezonedetect/wiki/Home" rel="nofollow">jsTimezoneDetect</a>) and save it on the server</li> <li>use the captured time zone for server-side calculations for the user</li> </ul> <p>Warnings:</p> <ul> <li>no matter what the mechanism, IP-based location detection is imperfect; I wouldn't use it for timezone detection</li> <li>most non-Windows systems use the <a href="http://en.wikipedia.org/wiki/Tz_database" rel="nofollow">tz database</a>; if your back end is Microsoft, you may need to <a href="http://www.timdavis.com.au/data/olson-time-zone-database-to-standard-windows-time-zone-v01/" rel="nofollow">convert</a> to Windows standard timezones</li> <li>while timezone detection is swell, things can go wrong, as some jurisdictions change time zones ad hoc;</li> <li>for your application, I predict most pain on time zone rule changes if you support recurring meetings; OS's usually include this in service packs</li> <li>you may consider a mechanism for the user to manually set the timezone (possibly after auto-detection)</li> </ul>
 

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