I saw a similar answer here Parsed date has minute difference but it's not exactly the same
I have a problem with google chrome. I have an application developed with GWT. This application sent an RPC to a server, and it get some data in return.
In this data there are some Date object. Seeing this date in EDGE and Firefox everything is ok but in Chrome they have 11 minute less.
I don't think it's a "code parsing" problem... because if I watch the RPC answer in Firefox and Chrome, I can see the RPC answer already wrong.
In firefox I see the object as "jsdate: Date 1800-01-01-01T07:30:00.000Z" and this is what I expect
In chrome I see the object as "jsdate: 1800 08:19:56 GMT+0049"
you can see image of devtool screenshot with the link below
firefox
chrome
In chrome version 69 i get this
In older version of chrome (for example 63) i get the same as firefox
Note that the time in Italy in 1800 was a bit different than now -
https://www.timeanddate.com/time/zone/italy/rome (pick 1800 - 1849 in "Time zone changes for:")
https://www.timeanddate.com/time/zone/italy
In Italy, standard time was introduced in 1893. Until then, the
country had been using solar mean time, based on Italy's longitude. It
was 49 minutes and 56 seconds ahead of GMT, then the world's time
standard.
In 1893, Italy advanced its clocks by 10 minutes and 4 seconds, so the
local time was exactly 1 hour ahead of GMT. The country still uses
this local time as standard time today.
So I am not sure this is a bug in Chrome, but a feature. I think Chrome simply updated their time zone data to include data for older times and it is now more accurate. Other browsers may follow suite at some point.
Since new Date(...) converts the input to the local time, the time zone is taken into account.
Related
When I was developing my Chrome extension I used the alarms API, and it worked without any issues. After uploading it to the Chrome Web Store, it doesn't trigger at the scheduled times (I am settings timers greater than one minute). I tested with a 5 minute timer, and it took 5 minutes and 47 seconds to trigger. I am considering switching to setting a timeout for the timers, but would prefer to use the alarms API. Below is a screenshot of the scheduled time going over the actual time.
Any ideas on how to fix this?
How much time will it take for Google to finish its review for a extension before it gets published to the Chrome Web Store?
Review times vary; some reviews complete in a few hours, others take many days, and in some cases a review can take several weeks
https://developer.chrome.com/webstore/faq#faq-listing-108
Long time no review, many days, few weeks. Our users can't wait. This is reason why we moved almost feature of extension from Chrome Extension to our own app
So it's weird. The review now take 10 days because they review all versions like its new. So if you make a push and have a small fix it's another 10 days. And sometimes it is more than 10 days.
This means a different strategy towards trying to get your extension deployed. First we are setting up a testing item in the Chrome Store Dev Section so that we can test our extension extensively in Chrome.
Second we are looking at using eval() in order to put our code in a wrapper. We already do this for FF and Safari. The real goal is to move more and more of the processing to the back end so that the need for a deployment becomes rarer.
This sounds like a lot of hoops but if you look at it from Chrome's end and the issues they have had around people doing bad things with extensions this is the price that has to be paid in order to be able to make extensions from their point of view.
I keep on typing in the google Colaboratory but it has happened three times now I left for like 2 minutes to check of some other things onto a web browser, at the same time 90 minutes finished and the runtime disconnected, which mean it wasn't idle for 90 minutes, it just disconnects me after 90 minutes anyways. Does it have to do with where I live maybe? India
I had this issue many times due to bad internet, if that's not case switch to GPU runtime and try.
I'm currently studying SSE's. In the w3 specifications it says:
A reconnection time, in milliseconds. This must initially be a user-agent-defined value, probably in the region of a few seconds.
Source: http://www.w3.org/TR/eventsource/#concept-event-stream-reconnection-time
How I understand this is that each webbrowser has a default reconnection time, but I can't seem to find the exact values?
From the footnote on p.65 of Data Push Apps with HTML5 SSE:
At the time of writing, it is 3 seconds in Chrome and Safari (see
core/page/EventSource.cpp in the WebKit or Blink source code) and 5
seconds in Firefox (see content/base/src/EventSource.cpp in the
Mozilla source code).
(I just checked and those are still the current values.)
I have a co-worker who has suddenly developed a problem with her Google Calendar. It seems that it has pushed her time slots up one, yet her timezone is correct, and we're in Saskatchewan, where we don't change our clocks!
Ex: Her meeting that she was supposed to have at noon, shows up in the 11am time slot.
The is a recent discovery. Is there a possibility that she did something, and everything shifted? It's not just for one day either, it's for all the events she has. She has it synced with her Blackberry, if that helps at all.
Any ideas, hints, etc are welcome!
I suspect that synchronization with the Blackberry may be to blame. For instance if it was created/synched with a BB device it may have put an incorrect time zone on the calendar event.
One way to check would be to go to Google Calendar and see what time zone is set for the event (It should be GMT - 6 Regina).