The random results are, frankly, broken. Others have pointed out that you say nothing about how to handle equal values when sorting. I learned something about F# here... Seq.sort is a stable sort and Array.sort is not. Your tests obviously use Array.sort. The problem here, is that for unstable sorts there's no documented behavior in this situation. The element orders could really be different on every run, and it would still be "correct". Moreover, different sorting algorithms will have different behaviors, so if Array.sort in the next version of the F# core libraries were to choose a different algorithm, your tests will have different results. Your tests either need to NOT include examples with duplicates, use a stable sort, or in some other way tell the CodeWarrior how to handle them. I feel cheated by this one, as I had to forfeit to even figure out all of this, and consider this to be a major failing of the Kata.

In F#, expecting an int as "the next item" when the list is a list of float makes absolutely no sense. Combine this with the ceil usage and solving this Kata just required guess work rather than actual real thought.

I don't believe there was any need to declare start as mutable? DateTime isn't a mutable type, and you don't reassign the binding?

Maybe as a casual developer, but I wouldn't want any professional developer writing a new LINQ operator if they don't understand the concept. Laziness is a key concept, and using LINQ or creating new LINQ operators without understanding this is dangerous. I've seen first hand the bugs that can be created by developers that don't understand this concept. I'd expect sites like this to be educating developers about this. That's why it's fine by me to make the explanation more clear, as Les did. I just had problems when you equated this to a "stupid" compiler implementation detail. It's neither stupid, nor a compiler implementation detail. It's implemented exactly as it must be for the concept, and the concept is a corner stone of functional programming, so not "stupid" in the slightest. It IS, however, surprising and unexpected for developers who are new to functional programming.

I don't have any problems with clarifying here, but it seemed pretty obvious to me. More importantly, though, I don't understand the comments about the behaviour being "stupid". It pretty much is how all generators work in every language, and it's the only way they SHOULD work. The entirety of a generator method by necessity of the concept must be lazy. If you want eager validation you have to separate the generator from the method that returns the result. This is a fundemantal concept you must understand when writing generators.

This solution works perfectly fine, but I wouldn't consider it "best practices" since it relies on side effects produced by the lambda passed to Where, which isn't functional. There's also a few inneficiences (this code does a lookup 4 times while you can accomplish this with only two lookups).

The input validation was not fully specified, and thus a really stupid part of this. Some of what you had to validate was nonsensical, requiring nothing more than guessing at what was being tested.