Discovered while helping with #59:
var dt = DateTime.local().setZone("UTC-5");
dt.toLocaleString(DateTime.TIME_SIMPLE) //=> '4:04 PM'
dt.hour //=> 11
dt.toUTC().hour //=> 16
In other words, toLocaleString() is showing the UTC time, not the UTC-5 time.
when I console log my DateTime object after setting the zone, it says 'LocalZone' still. Do you think this may be the issue?
Edit, sorry, it has changed. I'm still not getting the original time though after following method 1 in issue 59 ^
Should I maybe be using { keepCalendarTime: true } when I set the zone from the clock in point of the shift?
@SamMatthewsIsACommonName let's track your issue on the other ticket. This one is narrowly tailored to that bug.
Fixed in 1ca6871a829f3ccb8a74e2cb030621ec9da1c64a
I have a similar issue in last release (1.3.1) with DateTime.DATETIME_FULL:
var dt = DateTime.local().setZone("UTC-5");
console.log(dt.toLocaleString(DateTime.DATETIME_FULL))
console.log(dt.hour)
console.log(dt.toUTC().hour)
Console:
July 8, 2018, 10:08 PM UTC
17
22
See timestamp and date.
@mariomka Yeah, that is an unfortunate issue with the UTC[+-] zones; basically, V8 doesn't support it, so we do the best we can, which is to format the time accurately in UTC. This code comment describes the issue:
// Chromium doesn't support fixed-offset zones like Etc/GMT+8 in its formatter,
// See https://bugs.chromium.org/p/chromium/issues/detail?id=364374.
// So we have to make do. Two cases:
// 1. The format options tell us to show the zone. We can't do that, so the best
// we can do is format the date in UTC.
// 2. The format options don't tell us to show the zone. Then we can adjust them
// the time and tell the formatter to show it to us in UTC, so that the time is right
// and the bad zone doesn't show up.
// We can clean all this up when Chrome fixes this.
In theory, I could feature detect that and only make it fall back to UTC for Chrome and Node, but I'd like to keep it consistent. The underlying V8 issue hasn't shown any progress in a long time :(