toTimeString inconsistent time zone name

Question

I'm noticing the following weird behaviour for the toTimeString method.

const date1 = new Date("2022-09-23T00:00:00.00Z")
const date2 = new Date()


date1.toTimeString() 
//17:00:00 GMT-0700 (Pacific Daylight Saving Time)

date2.toTimeString()
// 15:06:43 GMT-0800 (Pacific Standard Time)

I've also noticed that result for date1 even depends on the device region settings (for Mac at least)

date1.toTimeString() 

// if region is set to Canada
// 17:00:00 GMT-0700 (Pacific Daylight Saving Time)

// if region is set to United States
// 17:00:00 GMT-0700 (Pacific Daylight Time)

Another observation

date2.toTimeString()
// this is the result for both United States and Canada
// 15:06:43 GMT-0800 (Pacific Standard Time)

A couple of questions

1. Why does the result depend on how the date is constructed? (new Date("2022-09-23T00:00:00.00Z") vs new Date)

2. For new Date("2022-09-23T00:00:00.00Z"), why does the result depend on the device setting?

3. The result seems consistent when no arguments are passed e.g new Date(). Can we assume that this will produce a consistent timezone name regardless of device settings?

Note: I also noticed a same behaviour with date-fns-tz

EDIT: added one more example above.

Another question: 4.In contrary to question 2, new Date().toTimeString() is not influenced by region setting. Why is that the case

EDIT 2: I figured it out. For countries with day light savings. The behaviour of toTimeString() will produce different timezone based on when the timestamp falls in.

Leaving this thread here since it might be helpful to others

Answer 1

1. First case you call the Date constructor with string representation of the date 2022-09-23 with the time 00:00:00 (GMT offset 0) and it returns the Date object instance for the 09/23/2022 00:00:00. Second case you call empty Date constructor which returns the Date object instance with current date and time.

2. Next, when you call the toTimeString() method it returns the time portion of a Date object interpreted in the local timezone (see more https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toTimeString).

3. If you would like to get the local time zone name better see here How can I get the timezone name in JavaScript?

Answer 2

1. Why does the result depend on how the date is constructed? (new Date("2022-09-23T00:00:00.00Z") vs new Date)

The timestamp "2022-09-23T00:00:00.00Z" is parsed with zero offset due to the trailing "Z". That effectively makes it UTC.

Calling new Date() creates a Date instance for the current date and time. toTimeString returns the time that a Date instance represents based on system settings. So for a given instance, if you change the location in system settings to a place with a different offset, you'll get a different time.

If regional settings are for a place that observes daylight saving time (DST), then you'll also get a different offset (and civil timezone name) for dates at times of the year when DST is and isn't in effect.

2. For new Date("2022-09-23T00:00:00.00Z"), why does the result depend on the device setting?

The Date instance created is exactly the same regardless of system settings because the offset is fixed as 0 in the timestamp. The result of toTimeString depends on system settings because that's were it gets its information for the host offset and civil timezone name from.

3. The result seems consistent when no arguments are passed e.g new Date(). Can we assume that this will produce a consistent timezone name regardless of device settings?

No. Timezone names are not standardised and are implementation dependent per ECMA-262. However, the actual offset should be consistent.

I suggest reading Why does Date.parse give incorrect results? for some background.