Q: What's the best way I can detect missing/ambiguous times?

Sorry for not using your issue templates! I have a question I’d like some advice on, I hope this is an okay place to post it.

This is about missing/ambiguous times. I’m sure it comes up all the time (as recently as #914) so I’m not here to request this as a feature that gets added, but rather, I’d like to ask what the best strategy is for working around this?

I have a website for sharing times across timezones (https://notime.zone) and I’m doing a rewrite using Luxon (it’s a lot easier to work with than moment 😄). I let people specify a datetime in my form, but I’d like to tell my users a few things:

• That no such time exists if they enter a time that was skipped due to DST (e.g. 2017-03-12 02:30, US/Eastern)
• That such a time is ambiguous if they enter a time that happened twice due to DST (e.g. 2017-11-05 02:30, US/Eastern)
  • Even better, offer them a way to specify which time they meant (if possible?)
• That, when VIEWING a CONVERTED time, if the result is ambiguous, that there are 2 possible meanings

And of course I would like to outright prevent the website from displaying a time that does not exist due to DST (however, I believe this Luxon will already do this).

So as I said I understand the reasons that luxon cannot account for / deal with these scenarios as part of its standard library. What I’d like to know from you is, what are the best ways I can detect these scenarios myself? It’s okay for my use-case to do a bit of poking around with nearby times to try and detect things and such and so forth, I’d just like to know the best approaches for this. Happy also to use the underlying Intl APIs if necessary.

[icambron]

however, I believe this Luxon will already do this

correct

The basic way to think about detecting these things is to figure out: given a local time and an offset, does the offset “tie out”? What I mean by that is: if you add the offset to the time to get a UTC time, and then compute the zones offset for that time, does it give you back the offset you plugged in?

Here’s how Luxon takes a local time figures out the corresponding UTC time it will build the DateTime around (bear with me here, this is going somewhere):

1. We don’t know the offset for this local time (we can only compute them for UTC times), but we guess one. This could be any guess, but Luxon uses the offset from now() in that zone.
2. We compute a “local timestamp”. This is Luxon’s core trick, and it’s a little subtle. If you know the local time, then you can pretend it’s a UTC time and get the epoch timestamp for that time. That UTC date will be a real date but off by the local offset, whatever that is. “Local timestamps” aren’t a real thing – they’re a trick Luxon uses to make the native Date system not try to make its own adjustments. Here’s how Luxon makes a local timestamp
3. You can add the guessed offset to the local timestamp, and ask the zone to compute its offset (using the Zone object, which for IANA zones uses Intl – but you can just use the zone object). Is the offset the same as your guess? If not, the guessed offset is wrong–it didn’t tie out–and needs to be adjusted by the difference. Now you know the real offset, and when you add that, you get the real UTC date.

All the logic for 3 is here. It’s probably Luxon’s most core function.

But–and this is the important part–notice a little lower down that function it tries to tie out the offsets a second time, and if that fails it decides its a hole time and does some hackery to advance it to after the hole. That’s because adjusting the offset by the difference moves the local time over the hole and misses it from the other direction. A hole time, to Luxon, is one for which it can’t find the offset that ties out.

OK, so armed with that, let’s go further: what if you could guess two offsets instead? Then you could see if they both tie out. If they do, then it’s an ambiguous time.

So that suggests this algorithm:

1. Probe around the date (say two days before and two days after) and get the offsets. Just use Luxon for this, like yourDT.plus({days: 2}).offset. These are like Luxon’s guesses in the algo above, except that–assuming the offset doesn’t change twice in four days–you’re pretty sure at least one of them is right, or should be.
2. Now see if those offsets tie out for the local time you have. If neither do, you’ve got a hole. If both do, you have an ambiguity.

There are a few gotchas here I can think of offhand (and remember, I’ve never actually tried this):

1. What if your probes land on holes or ambiguities? I guess pick more probes, like +2 days, +3 days, -2 days, and -3 days?
2. As you mentioned, Luxon won’t actually give you a hole time because it will advance the time for you, and the original provisional local time will be lost. So you need to capture that and construct the local timestamp before you put it into Luxon. That will actually make probing harder too…not sure what to do there.

Let me know how it goes if you try this!

P.S. that last complication makes me want to tag DateTimes with whether we advanced them over a hole time, which we do know, unlike ambiguous times.

[peabnuts123]

@icambron this might have gotten a bit lost in your mentions since the issue is closed 😃