Broadcast NotifyTimezoneChange to all RenderProcessHosts when the system time zone changes

content/browser/time_zone_monitor.h

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_BROWSER_TIME_ZONE_MONITOR_H_
+#define CONTENT_BROWSER_TIME_ZONE_MONITOR_H_
+
+#include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
+
+namespace content {
+
+// TimeZoneMonitor watches the system time zone, and notifies renderers
+// when it changes. Some renderer code caches the system time zone, so
+// this notification is necessary to inform such code that cached
+// timezone data may have become invalid. Due to sandboxing, it is not
+// possible for renderer processes to monitor for system time zone
+// changes themselves, so this must happen in the browser process.
+//
+// Sandboxing also may prevent renderer processes from reading the time

[bulach, 2014/04/29 08:33:44]

question: is it because the renderers are calling directly the platform-specific
local time function? would it be possible to:
- abstract renderers in all platforms to use something like our own
"LocaltimeCall"
- send the new timezone directly here, to keep the renderers fully
platform-agnostic?

[Mark Mentovai, 2014/04/29 16:01:05]

bulach wrote:
That’s pretty difficult to get right. The renderers would need their own time
zone specification data, since as I pointed out, it’s otherwise impossible for
them to read the system’s time zone specification files (/usr/share/zoneinfo).
It’s possible that we can use time zone data from ICU, but then we’ve got to be
extra careful to maintain and update that data, and we’re in an awkward
situation of mapping the system time zone in the browser process to an ICU time
zone to be used in the renderers, and mapping by name seems very fragile. As I
mentioned to Jeremy, the localtime calls in the renderers are found in
third_party code (even in ICU, hope there’s no circular dependency) so there’d
be a lot of local patching to replace these with our own custom localtime. And
if we got any of this wrong—and I’m sure there will be corner cases that we
won’t get right—we’d be in a situation where Chrome reports a different time
than the rest of the system. We could even get into a situation where some parts
of Chrome use Chrome’s idea of the local time zone (local times in web content)
where other parts use the system’s idea of the local time zone (navigation
history).

None of this sounds very good, and I really do prefer to continue using the
system’s time zone specifications to avoid these embarrassing mismatches.

+// zone when it does change, so platforms may have to deal with this in
+// platform-specific ways:
+//  - Mac uses a sandbox hole defined in content/renderer/renderer.sb.
+//  - Linux-based platforms use ProxyLocaltimeCallToBrowser in
+//    content/zygote/zygote_main_linux.cc and HandleLocaltime in
+//    content/browser/renderer_host/sandbox_ipc_linux.cc to override
+//    localtime in renderer processes with custom code that calls
+//    localtime in the browser process via Chrome IPC.
+
+class TimeZoneMonitor {
+ public:
+  // Returns a new TimeZoneMonitor object (likely a subclass) specific to the
+  // platform.
+  static scoped_ptr<TimeZoneMonitor> Create();
+
+  virtual ~TimeZoneMonitor();
+
+ protected:
+  TimeZoneMonitor();
+
+  // Loop over all renderers and notify them that the system time zone may
+  // have changed.
+  void NotifyRenderers();

[bulach, 2014/04/29 08:33:44]

nit: depending on the above, this would take the new tz to be broadcast

+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(TimeZoneMonitor);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_TIME_ZONE_MONITOR_H_