Invalid argument(s): Invalid return from platform getLocalTimezone()

[wckum]

Relevant code

final timezone = await FlutterTimezone.getLocalTimezone();

Getting this error in web on Chrome (Version 117.0.5938.132 (Official Build) (arm64)) using MacOS 14.0.. Any idea? Thanks for your effort!

[tjarvstrand]

Hey there, thanks for the report.

Without knowing what was actually returned to the plugin, it pretty hard to offer any insight. Maybe you could put a breakpoint inside flutter_timezone_web and see what the call to Intl.DateTimeFormat actually results in?

[vixez]

Hello @tjarvstrand , I have this issue as well. This only happens on MacOS 14 Sonoma.

I tried on several Mac's and all the Ventura ones are broken using any browser. For example, my timezone used to be Europe/Brussels on 13.5, but now since 14.0 it says it's CET.

In Terminal with sudo systemsetup -gettimezone I do still get Europe/Brussels.

[wckum]

Meanwhile I'm getting undefined for the value.. (not sure if this is what you're looking for)

Flutter doctor ( not sure if relevant) :

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.13.6, on macOS 14.0 23A344 darwin-arm64, locale en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 15.0)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.3)
[✓] VS Code (version 1.77.3)
[✓] Connected device (4 available)
[✓] Network resources

• No issues found!

[tjarvstrand]

Meanwhile I'm getting undefined for the value..

It seems like this is a browser/system problem. We rely on Intl.DateTimeFormat.resolvedOptions() to provide the timezone.

timeZone The value provided for this property in the options argument; defaults to the runtime's default time zone. Should never be undefined.

If this is not correct, I'm not sure what to do about it?

Could you try calling Intl.DateTimeFormat().resolvedOptions().timeZone; in the browser console?

For example, my timezone used to be Europe/Brussels on 13.5, but now since 14.0 it says it's CET

Though I understand how it can be problematic that this has changed, CET is a valid time zone. Even if you don't use it personally, you'll still have to take into account the fact that a lot of systems use abbreviated time zones rather than full names. flutter_timezone only returns what the underlying platform reports, so this must have changed in the browser(s) somehow.

[tjarvstrand]

BTW, @vixez

This only happens on MacOS 14 Ventura.

This version does not exist :) Do you mean MacOS 13 Ventura or MacOS 14 Sonoma?

[vixez]

@tjarvstrand

Oops you are right, I meant Sonoma 😄

I agree that this is a tough one to fix, I don't really know where to start looking to get it back to Europe/Brussels. In my app I do more calculations with timezones, and for this I use the flutter_timezone package in combination with the timezone package. The issue is that the timezone package does not accept CET as a valid timezone.

Since pretty much every user using my app is in the Europe/Brussels timezone, for now I catch it like this

  static Future updateLocalTimeZone() async {
    localTimeZone = await getLocalTimeZone();
    if (localTimeZone == 'CET' || localTimeZone == 'undefined') {
      //TODO: This is a MacOS 14 Sonoma issue
      //Ticket: https://github.com/tjarvstrand/flutter_timezone/issues/18
      localTimeZone = 'Europe/Brussels';
    }
  }

But of course this is far from ideal, or futureproof.

[wckum]

Seems like it's a system/browser issue then like you said... On chrome (even after latest update on Version 118.0.5993.70 (Official Build) (arm64)) it is still returning undefined .. On firefox it at least returns something .. I guess you can close this issue if you want...?

Relevant links regarding the chrome issue: https://support.google.com/chrome/thread/231926653/timezone-return-undefined https://bugs.chromium.org/p/chromium/issues/detail?id=1473422

[tjarvstrand]

But of course this is far from ideal, or futureproof.

Yeah, dealing with time is a PITA. If you're in a position to do so, I'd recommend you to do all your storage and calculations in UTC and only deal with time zones as close to the user as possible.

I guess you can close this issue if you want...?

Thanks. Given how thin this library is, I don't think there's much that can, or should be done about it here so I'll close this for now. Sorry I couldn't be of more help.