Side-effects of settings defaultZoneName

I came across this whilst trying to mock dates within tests, and found it rather un-intuitive, so thought I’d raise after having a quick check for any mentions previous.

As part of my tests, I wanted to change the timezone, so I changed the value of Settings.defaultZoneName in order to accomplish this. To unpatch the setting, I captured its previous value and re-instated, e.g.:

someTestCase(() => {
  let original;

  beforeEach(() => {
    Settings.defaultZoneName = 'Asia/Singapore';
  });

  afterEach(() => {
    Settings.defaultZoneName = original;
  });
}

However, after debugging and issue I found that this is not in fact restoring the original state:

• Settings.defaultZoneNameis really just a proxy to Settings.defaultZone
• Settings.defaultZone is initially a LocalZone instance because the private defaultZone variable is set to null
• As a result, when you set Settings.defaultZoneName to be anything, it is normalized to produce a non-LocalZone

The end result is that you end up with this, slightly confusing (at least in my mind) behaviour:

luxon.Settings.defaultZone
// OUT: LocalZone {}

// Set the defaultZoneName to equal its current value
luxon.Settings.defaultZoneName = luxon.Settings.defaultZoneName

luxon.Settings.defaultZone
// OUT: IANAZone {zoneName: "Asia/Singapore", valid: true}

My initial thought would be to have the defaultZoneName return null when the defaultZone is a LocalZone instance, but I’m not well enough versed in the Luxon codebase to understand the ramifications of that change.

[icambron]

I think I will make the breaking change you suggest, which is to make defaultZoneName return null by default. I think that should work fine for most cases, because internally Luxon is always looking for defaultZone itself, never the name.

[icambron]

Fixed in 2.0