Repro case:
// await initializeTimeZone(); // Works if you uncomment this line, not if you don't.final localTime = TZDateTime.utc(2019);
I would expect UTC-based TZDateTime to work without first loading the timezone database, since (by definition) UTC doesn't need any extra data to do its conversions or store its underlying data. But today if you don't call initializeTimeZone() you get the following error upon construction:
NoSuchMethodError: The method 'lookupTimeZone' was called on null.Receiver: nullTried calling: lookupTimeZone(1546300800000)
The underlying issue is that the internal _UTC constant is only initialized during initializeDatabase. AFAICT, it can/should just be a const defined at library creation time.
The benefit would be that e.g. simple tests that want to work with TZDateTime but can just use an arbitrary value for their tests would be able to create one using TZDateTime.utc without having to first load the database (which adds complexity and latency).
Repro case:
// await initializeTimeZone(); // Works if you uncomment this line, not if you don't.final localTime = TZDateTime.utc(2019);I would expect UTC-based TZDateTime to work without first loading the timezone database, since (by definition) UTC doesn't need any extra data to do its conversions or store its underlying data. But today if you don't call
initializeTimeZone()you get the following error upon construction:NoSuchMethodError: The method 'lookupTimeZone' was called on null.Receiver: nullTried calling: lookupTimeZone(1546300800000)The underlying issue is that the internal _UTC constant is only initialized during initializeDatabase. AFAICT, it can/should just be a const defined at library creation time.
The benefit would be that e.g. simple tests that want to work with TZDateTime but can just use an arbitrary value for their tests would be able to create one using TZDateTime.utc without having to first load the database (which adds complexity and latency).