Regex is overkill for anything.

If it's a very simple parse, like this, you'll get better performance and code that's easier to read by just writing it out imperatively. If it's a complicated parse, you'll be less likely to run into bugs, and have code that's easier to read, by using a proper parser DSL such as ANTLR. Regex isn't particularly good at either case, and its complexlity is extremely high. The "now you have two problems" joke exists for a reason.

Trim replaces the spaces only in the beginning or end of a string. It combines "TrimStart" and "TrimEnd".

I thought Trim erase all spaces!, Does this only trim the two sides?

Yes, including me, now. I just had to repeat the attempt until the random test let me pass.
I went with Seq.sortBy, which should behave the same as Array.sortBy - but obviously doesn't.
Would you be so kind as to include a short passage about standard collection functions mayhaps behaving differently to each other in the F# version used by Codewars? That would give a hint at what the problem may be.

Is regex an overkill for this one? Just asking because I'm not really familiar with regex.

i was wondering about using a LINQ ; but yeah Regex does the work

As mentioned more than 10 times below, it's not specified what should be done for equal sort keys. There's 1 reply where you said the sort should be stable, but it's not true, as at least in JS, F# and Ruby different, implementation-dependent results are expected.

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.

OK, no need.

That seems a POV, not an issue.

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).