You should have replaced $emp_stamp$ with something that's not straight out of PostgreSQL documentation.

More complex is good, because katas that require copying a simple formula and nothing more have been done, and are not very interesting. If it is new and complex it might be better.

Unpublished. Will change to Vincenty formula.
Is a bit more complex, but hopefully a new & unique challenge.

I will fix that. Sorry, I thought it might be unambiguous.
I hope "Return the distance as float. Do NOT round/ceil/floor" is clear and technically correct ?!

I have never heard of that, so that might be new.

If you're going to remodel the kata, would it be an idea to unpublish it in the meantime, so you don't accumulate solutions for a different problem?

Return the distance you calculated as a float with 13 decimals.

Nooooooooooooooo!

It is perfectly acceptable to require accuracy of 13 decimals ( though it's a bit many ), but do not specify anything that could be construed as rounding or truncating.

Read this and go forth and sin no more.

ETA: You didn't learn, did you?

Perhaps I can change the distance algorithm to Vincenty formula

Duplicate: https://github.com/Codewars/content-issues/wiki/List-of-Possible-Duplicate-Kata#haversine-distance

This can also be considered a duplicate of this kata (which goes much higher). Once the conversion to string is done, sorting alphabetically is trivial (I only had to copy paste my solution and do custom sort).

yeah, I mostly already deduced all of this. My point was rather that your description should be more explicit about all of this (you're entering the place of "long descriptions", where providing the information isn't always "enough": some well thought sections/summaries help a lot there, so that the needed info stands out more)

edit: don't forget to remove the rounding stuff from the description

Thanks a lot for your suggestions. I am new to kata authoring and wholeheartedly appreciate all kinds of inputs.
Let me quickly outline the assumptions I made for this kata, to make it more comprehensible:

• All directions refer to true north and for the sake of the kata, we assume that true north == magnetic north, was everything else would make things way more complicated. In the real world, wind not only changes with different locations, but also is different in different altitudes - in this kata we assume that wind is the same everywhere and in every altitude. Unit: degrees as float between 0 and 360 with a precision of 13 decimals
• Distances have to be calculated as the great-circle distance between two geolocations (orthodrome), which means the shortest distance over the earth’s surface, which an airplane would fly. Unit: nautical miles as float between 0 and 21639 nm with a precision of 13 decimals
• The heading required for the solution referes to the initial bearing between the coordinates when starting to follow the orthodrome - adjusted for the wind. I explicitly stated initial as the actual heading in-flight changes when flying larger distances following the orthodrome. Unit: degrees as float between 0 and 360 with a precision of 13 decimals. I will edit the description to clarify.
• Output type is an object with properties heading and time, representing the heading as described above and the flight time in minutes (distance / groundspeed * 60. Time is a float with a precision of 13 decimals and is between 0 and ≈ 25000.
• Additional assumptions:
  • All coordinations represent real airports.
  • Wind speed varies between 0 and 35 knots.
  • Airspeed varies between 50 and 250 knots. Windspeed thus always < airspeed.

I hope this helps understand the kata better.

there are weird assumptions in the task, imo...

• we are to considere actual globe/sphere
• but wind direction isn't given compared to the plane expected destination, and rather... I actually have no idea how it's given. Direction according to what? North? That should be clearly specified.
• we are assuming that the wind never changes of direction during the flight. Which is... weird. Not really a problem, but not natural either (especially if you imagine a complete circle around earth x) ). Would be better to just say it too.

• Heading must be in degrees and rounded to a whole number between 0 and 360. I believe this doesn't apply anymore => to remove
• It would be better to have an additional section describing quickly what the outputs are (types, units, ...). For now, I needed to scan the description 2 times to find the unit for the flight time. Same for the inputs, actually ("angle toward north", ...)

sounds reasonnable about the context. But what about actual testing of the correctness of the implementation?

Closing, but I'd prefere to see a shorter range of possible values, on my side.

The code doesn't use any rounding - test cases are precise up to 13 decimals. I am happy to share my solution if you are interested.
For the sake of navigating VFR flights you certainly don't need that much of precision - so I thought granting a tolerance of +- 1 might be a good tradeoff in case anyone uses rounding.

Added var R = 3440 as preloaded variable for the earth radius in nm for the sake of this kata.