Provide function to get the current system timezone name

[DartBot]

This issue was originally filed by [email protected]

---

It would be helpful if there was a cross platform way to fetch the iana time zone name for the server where the dart vm is currently running.

On Unix this is stored in /etc/timezone, for example on my computer it is "Pacific/Auckland".

I don't think this is always possible to do this correctly in the browser. Probably best to leave for a library there.

Note: DateTime.now().timeZoneName returns the abbreviated time zone name, which is ambiguous (CST Austrailia, and US), and differs depending on the time of the year. i.e. timeZoneName for me is currently NZDT, but in winter is NZST.

[lrhn]

cc @floitschG.

[lrhn]

Added Library-Core, Area-Library, Triaged labels.

[alanrussian]

The Flutter team I work on has a need for this. We can work around it by creating a plugin, but I would be happy to have this supported directly.

[mehmetf]

@floitschG Is there any way to escalate the priority of this? In Flutter-land, folks are talking about creating a plugin to get this information which would not be ideal as it leads to API confusion (VM or Plugin?).

[lifenautjoe]

Have you guys created a plugin for this yet? @alanrussian @mehmetf

[mehmetf]

@lifenautjoe I believe https://pub.dartlang.org/packages/flutter_native_timezone does this for now.

[mleonhard]

Please fix this in Dart. I really don't want to import yet another third-party plugin. Please provide usable timezone info.

[Jonas-Sander]

I believe https://pub.dartlang.org/packages/flutter_native_timezone does this for now.

It also does not work on the web

[fvisticot]

I believe https://pub.dartlang.org/packages/flutter_native_timezone does this for now.

It also does not work on the web

does not work on macos :(

[tstachl]

Considering this needs an implementation on the platform level (ios, android, web, ...), is the dart SDK the correct place to make this ask?

[alanrussian]

Couldn't you make this argument about a lot of existing APIs in the Dart standard libraries? I think it's a matter of whether this is useful enough to meet the threshold of residing in the Dart SDK. IMO it is since it's generally useful for date time handling and DateTime is in the Dart SDK.

[tstachl]

@alanrussian good point. It looks like there is not a lot of traction on getting it into the standard libraries, though. This issue was opened in 2014.

[mehmetf]

I agree this should be in the SDK. It is core functionality (and is currently in dart:core).

Dart needs to provide a better integration model than the current Flutter plugin approach when it comes to core platform fidelity. See issues like: #39104 where we need a way to bind dart:net to Cronet or OkHttp on Android. Same method can be used to bind dart:time to org.joda.Time on Android.

This is currently wishful thinking. I don't know what such a design would look like but it appears to me that a more modular approach to core APIs is needed. Another (and perhaps the biggest) problem is finding owners to such functionality. Ideally, a platform expert needs to maintain the backend of these core APIs and make sure they work on different OS versions etc. This is where the outsourced plugin approach currently falls short.

[mehmetf]

@mit-mit @mraleph This is another example use case which better interop can provide a good solution. It is odd to create an async API just to read timezone and yet that's what apps do today.

[mleonhard]

Dartlang & Flutter need this built-in for mobile. The third-party flutter_native_timezone library is unstable:
"Android ZoneID Crashes on Some Device/OS " pinkfish/flutter_native_timezone#25

CC: Flutter PM @timsneath

[tjarvstrand]

Is there any way to get movement on this issue? Given that time in general in one of the most notoriously error prone concepts to deal with in programming I would argue that this is an essential part of any programming language and especially one that is aimed at client-side programming.

[ekuleshov]

Not having proper IANA timezone info in the Dart/Flutter API on all supported platforms is a big interoperability issue.

Right now the DateTime.now().timeZoneName on MacOS returns EDT and on Windows it returns Eastern Daylight Time (which is not an IANA time zone name).

Most backend languages and frameworks (e.g. Java, .Net, Rails) needs IANA name in order to to convert times with the zone offset to a proper local time in a given timezone, to present to user on the UI or when exporting data in a user-friendly format.

[Pante]

Has there been any progress on this issue?

I recently finished implementing detection of the platform's timezone in sugar without async or a dependency on Flutter. It works across most desktop environments + partially on certain browsers, see this.

I'll be happy to PR support for desktop + web but I'm not sure exactly how to get started... or how to support Android/iOS without relying on method channels…

[lrhn]

The request here is for a way to get the IANA time zone name for the current local time.

That's information that is not directly derivable from the current DateTime data, so it needs to be provided somehow.

The first thing to decide is whether this is solvable at all: Can we get the information on all platforms.

You can get it in the browser, using Intl.DateTimeFormat().resolvedOptions().timeZone.
It gives me Europa/Paris, which I guess is technically the correct time zone, even if I'm not in France.
So it's possible on web.

On the VM, the currently exposed time zone name is provided by asking the operating system.
Is there something different we can ask, to get a different answer?
Windows has a GetTimeZone
I don't know if Linux, MacOS/iOS and Fuchsia has something similar. If they do, then it should be solvable.

If not, the VM can require the embedder to provide the necessary functionality, then they can decide how to solve it.
That's a larger, possibly breaking, change, since it requires all existing embedders to add new code to be compatible with it.

[Pante]

Fetching the IANA timezone on Windows, MacOS, Linux & web is do-able IMO.

For windows, what we wound up doing was calling GetDynamicTimeZoneInformation() using FFI and converting the standard time to an IANA timezone using the mappings in the CLDR-JSON repository.

On another tangent, it seems like the current implementation uses GetTimeZoneInformation() which may return a historical standard time. In my case, it causes DateTime.now().timeZoneName returns Malay Peninsula Standard Time instead of Singapore Standard Time . It isn't wrong but it's weird.

For MacOS/Linux, the local IANA timezone can be fetched by resolving /etc/localtime. It is necessary to do that in the VM/embedder? It feels like something that can be done in pure Dart, similar to what we did here.

Besides that, it would be nice if the TZ environment variable was supported as well but I don't think it's strictly necessary?

[lrhn]

Dart's DateTime only supports UTC-time and "local" time, because that's all JavaScript's Date supported. There is no plant to make it, or anything else in the dart:core platform library, Locale aware.

Providing the current time zone, not just the time zone offset, is a step towards locale awareness, and a reason I'd be happier to make it part of package:intl than dart:core.
Putting it in dart:core is the right answer if it requires deep platform/OS integration, because otherwise package:intl would need to know about all platforms that Dart may run on, which is not really their primary job.

[Pante]

Dart's DateTime only supports UTC-time and "local" time, because that's all JavaScript's Date supported. There is no plant to make it, or anything else in the dart:core platform library, Locale aware.

Providing the current time zone, not just the time zone offset, is a step towards locale awareness, and a reason I'd be happier to make it part of package:intl than dart:core. Putting it in dart:core is the right answer if it requires deep platform/OS integration, because otherwise package:intl would need to know about all platforms that Dart may run on, which is not really their primary job.

Perhaps I'm misunderstanding something, but all I'm suggesting is that DateTime.timeZoneName be changed to return a IANA timezone identifier instead of the standard time/offset I think that it'll be a good starting point for 3rd party libraries since retrieving the timezone across all platforms shouldn't be something that a library need to be concerned about like you mentioned.

[lrhn]

Changing the current behavior is ... potentially breaking, but since the behavior is as underspecified as it is, it might just be possible.

Then it becomes a matter of whether we dare do so, and whether we're able to get the necessary information on all platforms.
We don't just need the current time zone, we need the time zone for that actual time of the (non-UTC) DateTime object, which means historical time zones too.
Still, possibly possible.

[tjarvstrand]

...and whether we're able to get the necessary information on all platforms

I think it'd be fine to fall back to the current behavior (which I assume is supported on all platforms?) in the case that the IANA time zone isn't available. After all, if it's not there, it's just not there and there's no point in pretending.

[ThanhDat-Vo]

Are there any updates about this issue?