Discuss
  • Javascript Set Timezone Offset and time settings on Client

Javascript Set Timezone Offset and time settings on Client

# Iman Mohamadi (7 years ago)

To clear things out, I don't mean any changes to the actual Date time of Javascript. What I want to discuss about is a problem with a very simple solution.

Issue: Since Javascript code is mainly executed on a device that you might not have access to timezone and time settings that would be very help full to provide a way to adjust timezone and time settings that are taken from OS via Javascript code. Since now if you set your OS timezone setting to "Tehran" you will get -270 when you write this code in your browser console:

(new Date()).getTimezoneOffset();
>> -270

This is cool but what If I know I want to use another timezone? With current implementation I should mess around with date objects and do hacks and tricks but a very easy way would be to allow me to override OS preferences. That would be like so:

Date.setClientTimezoneOffset(300)    //Chicago timezone
(new Date()).getTimezoneOffset();
>> 300

Now I don't need to worry about myDate.getHours(), and minutes and seconds. Right now Javascript keeps this timezone offset to itself and leave me in pain of dealing with all incoming issues. However a simple set method could save a lot of time. This is the same with time settings. My browser takes time settings form my OS, if my OS time is 10:30 and I do this:

var myDate = new Date();
console.log(myDate.getHours());
>> 10

console.log(myDate.getMinutes());
>> 30

But what if correct time is 12:00 ? This can be annoying to fix how ever It could be handled in browser like this:

Date.setClientHours(12, 0, 0);
var myDate = new Date();
console.log(myDate.getHours());
>> 12

console.log(myDate.getMinutes());
>> 0

This can be implemented by keeping 12:00 - 10:30 = 1:30h which is OS to developer preference difference and use this offset to create correct Date.now(). If user changes it's time settings it can be set back to OS preferences.

What do you thing about the main idea?

# Isiah Meadows (7 years ago)

I'd personally prefer this to be settable on the instance, rather than the global object - you can manage universal dates more easily across time zones this way, and it still enables developers to have the fallback in case they need an escape or if they have code that relies on time zones remaining static as long as they have it and control creation. (The current Date.UTC stuff is not very helpful for anything not so simple you barely even need it.)

I'm not on the TC39 committee, so I can't really vote on this or anything, though.

Isiah Meadows me at isiahmeadows.com

Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com

# Oliver Dunk (7 years ago)

I’d love to have this use milliseconds rather than minutes, so that we could kill two birds with one stone. For example, I currently have my own NTP integration for a web project I run, and for that the offset from the actual time could be quite small.

# Iman Mohamadi (7 years ago)

About the milliseconds I agree with you. It could have the same API like setHours( hours [, minutes, seconds, mili-seconds] ) of date instance. I didn't talked about Idea of doing it per instance since I don't know about browsers and Nodejs implementations. That's why I need your opinion. But about doing it globally in your environment I'm sure it would be much much easier to implement.