Detecting Client Side Time Zone Offset Via Javascript

Dealing with time zones can cause some real pains. As a result when storing a date/time in an application it is standard to store the date/time as GMT. This makes it easier on the application in comparing dates, but isn’t very friendly for users. The next step is for an applications to provide an option to indicate what time zone dates should be displayed as. But what if we could skip that step and detect what time zone the client is in automatically? Turns out Javascript can help out here. The Date object has access to the time zone offset, here’s a simple function to get the number of hours the browser is plus or minus from GMT:

[sourcecode lang=”javascript”]
function get_time_zone_offset( ) {
var current_date = new Date( );
var gmt_offset = current_date.getTimezoneOffset( ) / 60;
return gmt_offset;

The getTimezoneOffset method of the Date object returns the difference in minutes from GMT, so dividing by 60 gives us the offset in hours. By grabbing the offset as part of a login form you can detect the time zone offset for each user automatically. An example HTML snippet might help make this more clear:

[sourcecode lang=”javascript”]
Time Zone offset: <span id="offset"></span>

<script type="text/javascript" src=""></script>

<script type="text/javascript">
function get_time_zone_offset( ) {
var current_date = new Date( );
var gmt_offset = current_date.getTimezoneOffset( ) / 60;
return gmt_offset;

$(‘#offset’).html( get_time_zone_offset( ) );

Save that as an HTML file, load it into your browser and it will show you what it detected for your time zone offset. If you do decide to use this as part of your login form be sure to filter it for only valid values. Never blindly trust data from a web browser. Keep in mind that it can be a negative number and a have decimal values (for those areas that don’t use whole hour offsets for their time zone).


  1. This works great! Thanks for the tip.

  2. A caveat: Date.getTimezoneOffset() returns positive numbers west of GMT and negative east of it. This means to get a proper offset, the result of that call needs to be made negative. After all, North American EDT is -0400, not +0400.

  3. Nice catch. I’ll have to update my example code to add the negative.

  4. Hi, this is cool, but doesnt do daylight savings time, I found this after your script broke on spring forward:


  5. Interesting, I’ll have to give that a read.

    As for daylight savings, that is likely always going to be a pain. JavaScript should know enough about the system it is running on to have the right offset. This puts the work of keeping daylight savings in sync on the operating system, where it belongs.

  6. Ricardo J. Parada

    Thu 11 Nov 2010 at 6:11 pm

    I used this Java code on the server to convert to a Joda DateTimeZone:

    int hoursOffset = clientTimeZoneOffset / 60;
    int minutesOffset = clientTimeZoneOffset % 60;
    DateTimeZone clientTimeZone = DateTimeZone.forOffsetHoursMinutes(-hoursOffset, minutesOffset);

    And on the client side I have something like this:

    $(‘clientTimeZoneOffsetField’).value = new Date.getTimeZoneOffset();

  7. Nice, but the drawback with only using the offset is that daylight savings is not taken into account. Another problem is that different timezones in the same UTC-offset often start daylight savings on different dates. For a more robust timezone you will have to do some checking of known dates.

    Check out which will give you a more accurate timezone as a result rather than just an offset. It is based on the code from that was linked above.

  8. Thanks for the link. In my particular case I was only after the numeric offset so the additional data wasn’t needed.

  9. Also doesnt work when you sit in colombia with a UK machine stating UK time. It wont get the offset. Do a timezone server call and get the zone based on your location.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2019 Joseph Scott

Theme by Anders NorénUp ↑