New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 154060 link

Starred by 29 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Oct 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Sign in to add a comment

Pepper Flash not setting local timezone in new Date object

Reported by, Oct 4 2012

Issue description

Steps to reproduce the problem:
We have had customers reporting that since the release of Pepper Flash they have seen timers on our site periodically jump forwards by 1 hour. We have a sports betting site and on busy days we can display over 100 sporting events at once, each one of those events has its own game timer. We have observed that when a large number of Date objects are created at the same time Pepper Flash sometimes sets the time zone in a new Date object to +0000 instead of the users local time zone (+0100 for our UK users). Once the time zone is incorrect it stays like that for 10 second then reverts back to the correct local time zone.

I’ve put together a demo to show this happening, here are the steps to reproduce:
•	Open up six new Chrome browser instances with Pepper Flash enabled
•	Go to this address in each browser instance:
•	Leave these instances running for 10-20 minutes and you’ll start seeing log entries showing the time zone changing

You can see the source for the demo swf here:

What is the expected behavior?
Creating a new Date object should always set the time zone to the clients local time zone.

What went wrong?
Pepper Flash Player intermittently sets the time zone in a Date object to +0000

Did this work before? Yes 25/09/12

Chrome version: 22.0.1229.79
OS Version: 5.1 (Windows XP)

UserAgent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
317 KB View Download
Labels: Feature-Flash
Status: Untriaged
Labels: Feature-Plugins-Pepper
Hi, please note that this is currently affecting an commercial website that as just over 4 million customers. We currently have a workaround for this, but with so many customers there are scenarios where the workaround is still not addressing the root cause. The website relies upon very accurate and timely information being displayed on screen in real time. This bug is causing us to mislead our customers with regards the information that is presented to them.

Comment 4 Deleted

Comment 5 by, Oct 10 2012

I am experiencing this issue as well on Windows 7 w/ Chrome 22.0.1229.92 and Flash version  I have seen dates/times change by 1 hour as well.  The timezone bounces between -0400 and -0500.  Could this be related to daylight savings time?
Hi, we are publishing a commercial FLEX calendar component (KCCalendar) and more and more customers report us weird issues with events “jumping” from 1 hour, day shifts (occurs on dates after the DST change date: 28/10) and other chaotic displays…
We have hundreds of customers, meaning thousands of users. This bug is really critical., you say having a workaround, can you please share it? I think it will be useful for other users running into this issue. Thanks in advance!

I put a sample application at

The application display 3 events respectively on 1/11/12, 2/11/12 and 3/11/12 (european format), starting at 12:00 and ending at 14:00. It logs every (last 200) generated date timezoneOffset property in the bottom text area.
To reproduce the issue you have to navigate to the 29/10 - 04/11 week and start moving the mouse over cells and items. If it doesn't work you can switch to month view and come back to week view and move the mouse on each view.

In France we start with -120 timezoneOffset but after a while it becomes -60 and if you go back in time it could be -120 again. You may also see events hours changing from 12-14 to 11-13.

Hope it will help for your tests and fix.

We tried two workarounds, first we tried getting the timezone offset from a javascript Date object using ExternalInterface. We could then compare the javascript offset with the flash offset and adjust the time in the flash Date object if the timezones where not the same. This did reduce the amount of occurrences of the issue but we found the javascript Date object to be unresponsive to timezone changes on your local machine. 

Our second solution which we are currently using is to create a Date object at the start of the application and store it's offset in a variable. Each time we create a new date object we check the offset against the stored offset and adjust the time if the offset has changed.

The second solution works well for us because we are using the Date object for countdown timers which don't need to be timezone aware, I'm not sure if this solution could be applied to your calendar application as I assume you'd want your application to be timezone aware.
Thanks a lot for your comments! As in our component, dates are almost everywhere (and as Date is final and can't be overriden) it will require to completely rework the component and you're right concerning the timezone awareness, hard to know the side-effects of such kind a solution in our case...
Is there any update on this? We've received issue reports from users of 2 different Flex applications that both suffer from this issue.

Since this really is a major issue, we're advising users to NOT use Chrome for now. I know this sounds drastic, but most of our users are not computer savvy enough to install the Adobe Flash Player and to disable the Pepper version.

Please consider this a high priority issue.
Labels: -Area-UI -Pri-2 -OS-Windows Area-Internals Pri-1 OS-All
Status: Assigned
Status: Started
I'm pretty sure it's a regression due to (I blame the reviewer of the change).
Project Member

Comment 13 by, Oct 18 2012

The following revision refers to this bug:

r162605 | | 2012-10-18T01:45:58.797599Z

Changed paths:

Make PPB_Flash_Proxy::GetLocalTimeZoneOffset()'s cache aware of the input time.

BUG=  (maybe also )

Review URL:
If the performance issue described in ticket 145854 is only the case on WinXP, can't the caching take place then only in that specific case?
Labels: Mstone-23 Merge-Requested
Status: Fixed
@kareng@: This bug is pretty serious, and the fix should pretty safe. Hold the merge request till it's been on Canary though.
 Issue 146918  has been merged into this issue.

Comment 17 by, Oct 18 2012

ok let me know when it's on canary and we'll merge it.

Comment 18 by, Oct 22 2012

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
Project Member

Comment 20 by, Oct 22 2012

Labels: merge-merged-1271
The following revision refers to this bug:

r163440 | | 2012-10-22T23:38:46.862217Z

Changed paths:

Merge 162605 to 1271 (M23) - Make PPB_Flash_Proxy::GetLocalTimeZoneOffset()'s cache aware of the input time.

BUG=  (maybe also )

Review URL:
Review URL:
 Issue 146918  has been merged into this issue.
 Issue 146918  has been merged into this issue.
Project Member

Comment 23 by, Mar 10 2013

Labels: -Area-Internals -Feature-Flash -Feature-Plugins-Pepper -Mstone-23 Cr-Content-Plugins-Flash Cr-Internals M-23 Cr-Content-Plugins-Pepper
Project Member

Comment 24 by, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 25 by, Apr 6 2013

Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
Project Member

Comment 26 by, Apr 6 2013

Labels: Cr-Internals-Plugins
Project Member

Comment 27 by, Apr 6 2013

Labels: -Cr-Content-Plugins-Pepper Cr-Internals-Plugins-Pepper

Comment 28 by, Jul 24 2013


Sign in to add a comment