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 <[email protected]> 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 > [email protected] > > 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 > <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
