We shouldn't block stable releases on a test case. Anyhow, to write an effective test for this, that will work on all macOS versions, whomever is familiar with all the date and ICU code should write a browser test to see that it works when the browser is actually running. I can help, but I don't know enough about that code to write the proper tests.

jshin@, how much work would it be to put that web-page you wrote (http://i18nl10n.com/chrome/tzchange.html) into a browser test?

The thing I don't know how to do is actually change the timezone because that requires admin privileges on the computer.

What I don't know is how to change the OS timezone on macOS.  Is it even possible to do that without 'root' access?  
If not, what would be a way to emulate the OS timezone changes?  

BTW, one browser test I mentioned elsewhere is to check that Intl.DateTimeFormat.resolvedOptions() does not have 'timeZone' field undefined. 

That alone would have caught  bug 773532  and related bugs. 

> What I don't know is how to change the OS timezone on macOS.

I meant that I don't know how to change it in a program (a browser test or whatever test I write). 

Setting the TZ environment variable is likely to change the timezone as detected by Chrome or its test program, but it would not test what was broken due to a recent change in macOS 10.13 (the location and the organization of zoneinfo and other tz related files and directories.)

I'm not sure how to write this test for the same reason: how do we change the OS timezone on the fly in an unprivileged test? I don't think it can be done.