392274 - should _tzset on Win32

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Mike Perry]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

It would be nice if Firefox 3.0 provided either an about:config option or a chrome API to change the timezone of the browser from the OS value. This would be useful both for travelers who frequently move about and would like to change their browser's timezone without restart or independent of the OS (ie just for webmail, etc), and also for users of the Tor privacy network who would like to protect their location information.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Perry]

This is how I envision the fix working: Basically, add javascript.options.TZOffset and javascript.options.TZString prefs. Then, nsJSContext::JSOptionChangedCallback in dom/src/base/nsJSEnvironment.cpp would for listen changes to these prefs, and pass them to a new JS_SetTZOptions call in jsapi.c. This call would update the JSContext to store these values. If they were set, js_InitDateClass would use the offset for LocalTZA, set an additional SpoofedTZA flag indicating the timezone was faked. DaylightSavingTA would then return 0 if SpoofedTZA is true.

Additionally, it looks like we would need to bypass calls to PRMJ_FormatTime in date_format and date_toLocaleHelper to change the timezone string to the spoofed string. Would there be any issues with this approach?

Comment 2

[Mike Perry]

Turns out there is an alternate way to do this. Most operating systems I've tested (Linux, MacOS, BSD, Windows) will obey the TZ environment variable for their localtime() implementations, and have a common format for this variable. Changes to this environment variable done via nsIEnvironment can be used to update the timezone.

However, the notable exception is Windows. Windows, while it supports the TZ variable with the same format as the Unices, does need to be informed of updates to this variable via a call to _tzset() (http://msdn.microsoft.com/en-us/library/90s5c885(VS.80).aspx). If we added such a call to say PRMJ_LocalGMTDifference() for Windows platforms, extensions could then reliably set the timezone in a cross-platform way by simply setting the TZ variable.

This would not take effect in existing windows, but all new windows would then have an updated timezone offset, which is fine for Torbutton's purposes. Since this would just be a one line change inside an #ifdef for XP_WIN, it may be preferable to the more complicated solution involving preferences.

Comment 3

[Mike Perry]

Attachment: TZ environment fix for FF3.0 (1.9.0)

Calls _tzset() on windows platforms to read in the the TZ environment variable
before adjusting for timezone. Allows Torbutton and other addons to change the timezone by using @mozilla.org/process/environment;1

Comment 4

[Mike Perry]

Attachment: Same patch for FF3.1 (1.9.1)

Calls _tzset() on windows platforms to read in the the TZ environment variable
before adjusting for timezone. Allows Torbutton and other addons to change the timezone by using @mozilla.org/process/environment;1

Comment 5

[Samuel Sidler (old account; do not CC)]

Comment on attachment 370977 [details] [diff] [review]
TZ environment fix for FF3.0 (1.9.0)

This needs review before it will receive approval anywhere.

Comment 6

[Samuel Sidler (old account; do not CC)]

Sending to Core::JavaScript Engine since that's where this file is.

Comment 7

[Brian Crowder]

Would be nice to base this on a configure check, rather than on XP_WIN, localtime_r should be a good example of that.

Comment 8

[Mike Perry]

I can add an autoconf check for _tzset, but this behavior of tzset is specific to Windows. POSIX says that time-related library functions should call tzset if necessary automatically. So its likely that Windows is the only OS that needs to make the call.. but it is also the case that extra calls should be harmless.

So, do we want to do an ifdef check for both XP_WIN and HAVE__TZSET (from an autoconf test for _tzset())? Or is the check for _tzset enough?

Comment 9

[Brian Crowder]

I think the check for _tzset is enough (since only Win32 currently seems to use the weird "_"-for-all-non-std-but-should-be-functions convention.  On my Mac, it's "tzset"

Comment 10

[Mike Perry]

Ok, so I lied. I can't add an autoconf test for _tzset.. I tried to create an AC_CHECK_FUNCS for it and it ends up failing because cl can't find any of the system libraries.. I think this is a problem with how configure itself is launching cl. 

Believe it or not, it looks like there are no AC_CHECK_FUNCS done on Windows. All the check results are hardcoded via the $target switch statement. The few HAVE_ defines that the Windows build uses are actually set manually via AC_DEFINEs. Search for HAVE_SNPRINTF in configure.in and see what I mean.

I hope this doesn't mean this patch is blocked until I fix autoconf to work properly on windows ;)

Comment 11

[Brian Crowder]

No, I was just hoping for better.  I thought our AC_CHECK stuff did work on Windows, but it seems I was mistaken.

Comment 12

[Brian Crowder]

Comment on attachment 370977 [details] [diff] [review]
TZ environment fix for FF3.0 (1.9.0)

This is pretty minor, my feelings won't be hurt if you say no.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 370978 [details] [diff] [review]
Same patch for FF3.1 (1.9.1)

a191=beltzner

Comment 14

[Brian Crowder]

http://hg.mozilla.org/mozilla-central/rev/bc26f4f350fd
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b6b3a5258458

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: fixes windows ce bustage

This push broke the windows ce build because it doesn't have _tzset (windows ce doesn't have environment variables)

Comment 16

[Brian Crowder]

Comment on attachment 373006 [details] [diff] [review]
fixes windows ce bustage 

ugh!

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

pushed http://hg.mozilla.org/mozilla-central/rev/c97277efcd07

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 370977 [details] [diff] [review]
TZ environment fix for FF3.0 (1.9.0)

Need a 1.9.0 patch with the wince bustage fixes after those land on 1.9.1 successfully.

Comment 19

[Benjamin Smedberg]

Comment on attachment 373006 [details] [diff] [review]
fixes windows ce bustage 

limited-time approval... if this doesn't land by tomorrow or so it'll have to wait for 1.9.1.1

Comment 20

[Doug Turner (:dougt)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b32e55fa20af

Comment 21

[Mike Perry]

Can we get this backported to 1.9.0 now?