1

I have written a helper function to attempt to parse a time string in a flexible way. Sometimes the time comes in as a full date but sometimes its just a string like "10:30" or "12:01 PM".

So I am checking to see if I can parse the date first:

let date = new Date(value);
if (!isNaN(date.getTime()) // its a valid date

If that fails then I fall back to regex to check if I can make any sense of the string manually:

const isValidTime = /^([0-1]?[0-9]|2[0-4]):([0-5][0-9])(:[0-5][0-9])?(\s?(AM|PM))?$/i.test(value);

While writing unit tests I found some weird results. Incorrect times were returning actual dates in stead of throwing an error. Javascript new Date() is parsing some of the strings and seemingly making up dates for them but also strangely, its getting the hour right too. Here are some examples of time strings that are causing this:

new Date("1:60") // Fri Jan 01 1960 01:00:00 GMT+0200
new Date("2:70") // Thu Jan 01 1970 02:00:00 GMT+0200
new Date("3:80 PM") // Tue Jan 01 1980 15:00:00 GMT+0200

//and a "valid" time for good measure
new Date("5:30") // Invalid Date

What the heck is going on here?

JeffJenk
  • 2,575
  • 2
  • 21
  • 28
  • https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/Date#parameters – phuzi Mar 08 '21 at 15:51
  • and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#parameters – phuzi Mar 08 '21 at 15:54
  • 2
    "*What the heck is going on here?*" you're giving JS non-standard date strings that will be *more than usual* subject to implementation dependent behaviour. I'm not sure what's so surprising. – VLAZ Mar 08 '21 at 15:55
  • I am passing it a string that is not a date. I don't think its unreasonable to use this interface to establish if a date is valid. – JeffJenk Mar 08 '21 at 16:06
  • 1
    "*I am passing it a string that is not a date.*" correct. You're passing it to the *Date* object. It's not at all unreasonable to expect that not-a-date string will not necessarily be read as a date. Besides, pretty much every single date parsing function or library, in any language, will have an issue if you pass a random string into it. Some are over-eager and try to accept anything that *extremely vaguely* can be classified as a date using what can only be described as the intersection of dream logic, parsing designed by M. C. Escher, and a decade of bugs converted into features. – VLAZ Mar 08 '21 at 16:20
  • 1
    As pretty much always - what is "reasonable" for some function/method/whatever to do should be laid out in the documentation. That doesn't only apply to date manipulation and interpretation but *you most especially **MUST ALWAYS*** check the documentation for anything date related. I cannot stress this enough - there is no markup for giant flaming letters that will sear themselves in your retinas for a week. Date interpretation is the land of insanity. Documentation is the only thing that could give the method to it. – VLAZ Mar 08 '21 at 16:24
  • Thanks @VLAZ its clear my assumption that I could use this to parse a string with any sort of certainty is _unreasonable_. Date interpretation is indeed the land of insanity. We opted to parse the string more manually in stead which still feels like a compromise. It feels like the optimal solution is to control our input better, but we have to work with the data we have ‍♂️ – JeffJenk Mar 09 '21 at 15:03

0 Answers0