Add getNextDST() and getLastDST() functions

[petrgazarov]

Resolves #266.

Adds getNextDST() and getLastDST() on tz with an option to pass in a date or moment object as an argument (to be used as benchmark when calculating the result). If no argument is given, compares to current time of the guess()ed zone.

Would be happy to add docs once code is approved. Thanks!

[petrgazarov]

I saw this locally too - not sure why the tests are failing. If you run :core only, they pass. When the whole suite is run, untils array ends up with only [ Infinity ] in it, which makes me think something is not properly loaded.

[getriebesand]

please hook is to the Zone Object, and name the functions getNextTransition and getPreviousTransition because not all Transitions are DST Transitions.

[drmrbrewer]

What's the status of this feature? (I'm not too familiar with the way changes are progressed in a library such as this.) I'd love to see these functions implemented, not only the next DST transition relative to now, but the next one relative to a specified UTC time. Are they in a beta version or anything? I could knock something up for my own purposes using untils but I'd rather not re-invent the wheel if it has already been invented.

[petrgazarov]

Hey @drmrbrewer, sorry about the delay. If you would like to take this on, I believe the feature is complete on my branch. Just need to pass tests. Thanks!

[wayofthefuture]

+1

[ichernev]

If it's just a for loop over some offsets, it could be done as a binary search (maybe not worth it if the changes are less than 100). I'm not sure the guess() call is warranted, but getting next/previous transition from a timestamp is a nice feature. It should be well defined in case it matches the timestamp as well.

[Lev-Shapiro]

@ichernev I was searching for a project to contribute to, all these open pull requests weren't published because there are some problems in the code, right? So that means if someone will fix it - it will be merged?