fromObject and toFormat("T") use different timezone when timezone is changed

We are currently relying on the property that

DateTime.fromObject({hour: 13, minute: 13}).toFormat("T") === "13:13"

is true in all situations (minus locale formatting for the separator). Is this a wrong assumption?

This is in a react-native context, and what happens is that when the app is open and the user changes the device’s timezone and goes back to the app, the condition above doesn’t hold. It seems that fromObject is using a different zone than what toFormat("T") is.

I can also confirm that Settings.defaultZone does not get changed when switching timezone in the app, so that value is not in sync with new Date().getTimezoneOffset() after the timezone has been changed.

[anttih]

Thanks for taking a look at this!

For some reason calling Settings.resetCaches() does not work either. Might have something to do with how react-native caches modules. And anyhow we would like to not use that hammer approach here.

The reason why luxon is such a great library is that it has a more functional API to dates than moment.js. This behaviour goes against that philosophy and I would personally pay the performance penalty rather than have a stateful API.

A common real world use case for experiencing this bug is with mobile applications. You open the app, go to a plane and cross a timezone. You go back to the app and see that all times are off.

[icambron]

This behaviour goes against that philosophy and I would personally pay the performance penalty rather than have a stateful API.

It’s not a stateful API, just a bug. Almost every immutable library ever uses caching; in fact, one of the nice things about immutability is that you can cache so aggressively, because nothing can change. Statefulness is about the API and its expectations, not the any private state underneath. Here it’s just that the private state is managed wrong.

That you would pay a 100x performance penalty to fix that bug makes you an outlier, since I’ve never even seen this one before. I’m not denying it’s a real problem, just saying that the cure is for most users worse than the disease; slowing the library down by two orders of magnitude would bring countless applications to their knees. One of the hard parts of maintaining a widely-used open source library is that you can’t please everyone all the time.

But I did think of a better workaround:

DateTime.fromObject({hour: 13, minute: 13, zone: DateTime.local().zoneName });

That works by paying the performance penalty on object creation. Since the zone to format in is now explicit, it’s part of the cache key and everything works.

You can use that conveniently like this:

DateTime.fromObjectLocal = function(o) {
   var realO = Object.assign({}, o, { zone: DateTime.local().zoneName });
   return DateTime.fromObject(realO);
};

(though note that in the upcoming 2.0, it’s fromObject({ hour: 13, minute: 13 }, { zone: ... }))

---

Re, your second issue: I can’t reproduce that, and I’m confident the code doesn’t cache anything there. In fact, my workaround above wouldn’t even work if that happened. The implementation of that is here; you can see it’s constructing a new Intl.DateTimeFormat object to check what zone it resolves. So you must have something else going on there?

You might try confirming you’re getting different values from Intl before and after your switch:

new Intl.DateTimeFormat().resolvedOptions().timeZone //=> shouldn't still be Helsinki

If that’s doesn’t work, something much deeper than Luxon is broken.