Javascript Set Timezone Offset and time settings on Client

[Iman Mohamadi]

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.

On Sun, Apr 29, 2018 at 9:39 PM Oliver Dunk <oliver at oliverdunk.com> wrote:

> 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.
>
> > On 29 Apr 2018, at 18:07, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> >
> > 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
> >
> >
> > On Sun, Apr 29, 2018 at 12:49 PM, Iman Mohamadi
> > <iman.mohamadi.dev at gmail.com> wrote:
> >> 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?
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180430/fb0cca24/attachment.html>