You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using TZDateTime correctly is a core part of this package. As such, the user needs to understand a bit of how package:timezone works. While writing the new usage guide, I realized that there is mainly one correct way to do this, and based on the example, I think it looks like this:
import'package:flutter_timezone/flutter_timezone.dart';
import'package:timezone/data/latest_all.dart'as tz;
import'package:timezone/timezone.dart'as tz;
voidinitTimezones() {
if (kIsWeb ||Platform.isLinux) return;
tz.initializeTimeZones();
if (Platform.isWindows) return;
final timeZoneName =awaitFlutterTimezone.getLocalTimezone();
tz.setLocalLocation(tz.getLocation(timeZoneName!));
}
From this point on, users can simply use tz.local to get their current tz.Location. So maybe instead of making everyone copy this snipper and adding both packages, maybe we can offer this as a top-level function and only make users include package:timezone, but not need to use getLocation and setLocalLocation themselves.
The text was updated successfully, but these errors were encountered:
To be more precise it's considered core only for those that need to schedule notifications. Putting that aside, I understand the intent but this is better placed in to reside in another (helper) package . This proposal forces this plugin to depend on flutter_timezone and in turn brings in an additional dependency upon apps that may not need. It can also bring about another potential point of failure that has been an issue before with the plugin this forked from. I think I had made a similar comment elsewhere, perhaps when one of your PRs that wanted to use msix (?)
Using
TZDateTime
correctly is a core part of this package. As such, the user needs to understand a bit of howpackage:timezone
works. While writing the new usage guide, I realized that there is mainly one correct way to do this, and based on the example, I think it looks like this:From this point on, users can simply use
tz.local
to get their currenttz.Location
. So maybe instead of making everyone copy this snipper and adding both packages, maybe we can offer this as a top-level function and only make users includepackage:timezone
, but not need to usegetLocation
andsetLocalLocation
themselves.The text was updated successfully, but these errors were encountered: