Hi this bug is affecting me on Chrome Version 64.0.3282.140 (Official Build) (64-bit)

Tested the issue on chrome reported version 64.0.3282.140(as per comment#2) using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome with TZ=:/etc/localtime, after chrome got launched it is showing as site cannot be reached
2) In NTP, opened Devtools > Console and executed the command Intl.DateTimeFormat(), got output as "DateTimeFormat {}"

@Reporter:
Please find the attached screen cast for your reference and provide your inputs on it which helps us in further triaging it.

Thanks!

Deleted: 811403.ogv 2.7 MB

	811403.ogv 2.7 MB View Download

@Comment 3

You must run the command with setting the environment variable first, otherwise it is interpreted as arguments to the 'google-chrome' command.  Please run it like this:

    $ TZ=:/etc/localtime google-chrome

Also make sure that /etc/localtime is symlinked to a time zone file.  In my case:

    $ ls -l /etc/localtime 
    lrwxrwxrwx 1 root root 35 Nov 19 23:04 /etc/localtime -> /usr/share/zoneinfo/America/Chicago

My system:
OS: Ubuntu 16.04.3 LTS
Kernel: 4.4.0-98-generic #121-Ubuntu SMP 

sorry, comment #4 is correct, when i said "run browser with TZ=:/etc/localtime", i meant that you need to set the TZ environment variable to :/etc/localtime

Thank you for providing more feedback. Adding requester "viswa.karala@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Also affecting me.
Chromium Version 64.0.3282.140 (Official Build) Built on Ubuntu , running on Ubuntu 17.10 (64-bit)

Steps to reproduce:  in the javascript console (Ctrl-Shift-I):

> Intl.DateTimeFormat()
>  Uncaught RangeError: Unsupported time zone specified undefined
>   at Object.DateTimeFormat (native)

> (new Date()).toLocaleString()
>  Uncaught RangeError: Unsupported time zone specified undefined
>   at new DateTimeFormat (native)
>   at Date.toLocaleString (native)

Other info:

> Date()
>  "Fri Feb 16 2018 17:49:37 GMT-0500 (EST)"
> (new Date()).getTimezoneOffset()
>  300

So the class method shows me the correct timezone in it's string, and .getTimezoneOffset() shows the an offset in minutes from GMT (wait shouldn't it be -300 minutes?)  This indicates the time zone is not undefined, but .DateTimeFormat() complains the time zone is undefined.

I have attached a basic test page for this issue

Both of the following give an error in Chrome. I did not experience this issue in an older build, although I do not know what version broke this

TZ=/usr/share/zoneinfo/America/Phoenix google-chrome-stable 
TZ=:/etc/localtime google-chrome-stable 
Chrome Version 64.0.3282.167 (Official Build) (64-bit)


I have also attached the output of "TZ=/usr/share/zoneinfo/America/Phoenix firefox" and "TZ=/usr/share/zoneinfo/America/Phoenix google-chrome-stable" to exhibit the issue

Deleted: intl-datetimeformat.html 310 bytes

intl-datetimeformat.html 310 bytes View Download

Deleted: chrome-intl-datetimeformat.png 5.9 KB

	chrome-intl-datetimeformat.png 5.9 KB View Download

Deleted: firefox-intl-datetimeformat.png 2.2 KB

	firefox-intl-datetimeformat.png 2.2 KB View Download

I have determined that this is a bug in chrome's handling of glibc's localtime method

When TZ is not set, chrome behaves properly, although this stat(2)'s /etc/localtime dozens of times a second in some cases. TZ=:/etc/localtime is also the default on many systems

With TZ set, chrome only opens and reads the file at launch, and shows the incorrect behavior shown in this thread

I have personally worked around this by editing my chrome launcher to "unset TZ" before launching chrome, but I would prefer an actual fix

 Issue 818074  has been merged into this issue.

I do have the same issue on Version 65.0.3325.162 (Developer Build) (64-bit) (from https://www.archlinux.org/packages/extra/x86_64/chromium/)

Console > new Intl.DateTimeFormat('en-US', { timeZoneName: 'long'}).resolvedOptions()

Result > VM476:1 Uncaught RangeError: Unsupported time zone specified undefined
    at new DateTimeFormat (/p/chromium/issues/native)
    at <anonymous>:1:1

I've been able to fix sites that are broken by this bug using an extension/userscript that applies the following wrappers at document start:

(function() {
    Date.prototype.toLocaleString = Date.prototype.toString;
    Date.prototype.toLocaleTimeString = Date.prototype.toTimeString;
    var delegate = Intl.DateTimeFormat;
    function DateTimeFormat() {
        var args = Array.prototype.slice.apply(arguments);
        args[0] = args[0] || 'en-US';
        args[1] = args[1] || {};
        args[1].timeZone = args[1].timeZone || 'America/Toronto';
        return delegate.apply(this, args);
    }
    DateTimeFormat.prototype = delegate.prototype;
    Intl.DateTimeFormat = DateTimeFormat;
})();

Others using this workaround will likely want to set their preferred locale and time zone appropriately. I suspect it's also possible to use better wrappers for Date.toLocaleString and Date.toLocaleTimeString that preserve semantics.

What Linux distros set TZ to ":/file/path"?  

Anyway, this issue is due to ICU's timezone detection not handling TZ set to ':/file/path'. I'm going to file a bug against ICU. 

It's not just :/file/path. Here's the value from my system, which is affected by this bug:

TZ=/usr/share/zoneinfo/America/Toronto

http://bugs.icu-project.org/trac/ticket/13694 is an upstream bug. 


> TZ=/usr/share/zoneinfo/America/Toronto

What distro is that?  According to http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html , it has to start with a colon. 

So, I made an explicit condition to check that. Given what glibc actually does, I guess I have to remove that check. 

TZ=/usr/share/zoneinfo/America/Toronto date
Tue Apr 10 19:18:11 EDT 2018


Anyway, a much simpler override is to unset TZ before starting Chrome. 

https://chromium-review.googlesource.com/1006219 is a CL. 

The TZ value on my system was set manually, not as part of a distro default. Apparently I set up my environment wrong sometime 2015 or earlier, and it hasn't come to light until now (probably because in practice glibc is okay with it). In short: don't take it as a configuration that you need to support :)

Thanks for taking the time to investigate and report upstream!

> The TZ value on my system was set manually, not as part of a distro default.

Oh... Thanks for the clarification. In that case, this bug is not P1. 

Anyway, I already made a CL and tested it. (see comment 18). 
 

Ignore my previous comment, i seem to have edited that file on the suggestion of https://blog.packagecloud.io/eng/2017/02/21/set-environment-variable-save-thousands-of-system-calls/

So yes, not P1

 Issue v8:7906  has been merged into this issue.

This is not a corner case for us, as we run as a server and we embed v8, and we need to set TZ to :/etc/localtime for performance reason.  We cannot upgrade v8 to the latest version due to this regression.