Is it better to parse string to convert to Date or let JavaScript do it?

Question

I currently have a function that will convert a string to a Date object, the string may contain or not time information, if it doesn't I set hours and minutes to 0:

const stringToDate = string => {
  const [, y, m, d, h = 0, min = 0] = string.match(/(\d{4})-(\d{2})-(\d{2})(?: (\d{2}):(\d{2}))?/)
  return new Date(y, parseInt(m) - 1, d, h, min)
}

console.log(stringToDate("2017-07-09"))

I wonder if it would be more performant and or more reliable if I would just rely on Date object to do it for me like so:

// Replace '-' with '/' for Safari.
const stringToDate = string => new Date(string.replace(/-/g, '/')) 

console.log(stringToDate("2017-07-09"))

I am aware the Date methods behave differently according to browser (e.g. Safari can't read '-'), and I am also concerned about daylight saving possible errors. Are both ways safe?

Could not find an answer in Converting a string to a date in JavaScript

Answer 1

TL;DR

Using new Date() is faster, both methods are reliable - tested on Chrome, Firefox, Safari.

I wrote test cases on 5 years for the 2 functions. Then I have run benchmark tests on Chrome, Safari, and Firefox to compare them, here are the results:

https://jsperf.com/string-to-date-regexp-vs-new-date/1

Same results on jsbench.me:

We can see that using regexp is slower for all the cases, (and that Safari is slower than other browsers for this operation).

I also added a check in both cases to validate that the calculated date from stringToDate function is always correct on 5 years (that obviously crosses 10 DLS dates and at least 1 leap year).

If the returned date would be erroneous, the loop would have ended in an error, here are my tests:

1. Via regexp

const stringToDate = string => {
  const [, y, m, d, h = 0, min = 0] = string.match(/(\d{4})-(\d{2})-(\d{2})(?: (\d{2}):(\d{2}))?/)
  return new Date(y, parseInt(m) - 1, d, h, min)
}

let tmpDate = new Date()
for (let i = 0; i <= 365 * 5; i++) {
  let y = tmpDate.getFullYear()
  let m = tmpDate.getMonth()
  let d = tmpDate.getDate()

  tmpDate = new Date(y, m, d + 1, 0, 0)
  y = tmpDate.getFullYear()
  m = tmpDate.getMonth() + 1
  d = tmpDate.getDate()

  const tmpDateFormatted = `${y}-${m < 10 ? '0' : ''}${m}-${d < 10 ? '0' : ''}${d}`
  const calculatedDate = stringToDate(tmpDateFormatted)
  // console.log(calculatedDate)
  
  if (calculatedDate.getTime() !== tmpDate.getTime()) {
    console.error('Wrong date.', calculatedDate, 'should be', tmpDate)
  }
}

2. Via new Date()

// Replace '-' with '/' for Safari.
const stringToDate = string => new Date(string.replace(/-/g, '/')) 

let tmpDate = new Date()
for (let i = 0; i <= 365 * 5; i++) {
  let y = tmpDate.getFullYear()
  let m = tmpDate.getMonth()
  let d = tmpDate.getDate()

  tmpDate = new Date(y, m, d + 1, 0, 0)
  y = tmpDate.getFullYear()
  m = tmpDate.getMonth() + 1
  d = tmpDate.getDate()

  const tmpDateFormatted = `${y}-${m < 10 ? '0' : ''}${m}-${d < 10 ? '0' : ''}${d}`
  const calculatedDate = stringToDate(tmpDateFormatted)
  // console.log(calculatedDate)
  
  if (calculatedDate.getTime() !== tmpDate.getTime()) {
    console.error('Wrong date.', calculatedDate, 'should be', tmpDate)
  }
}

Hope it helps someone!

Answer 2

Your regex implies that you are using non-standard date time formats which fail for example in Safari. And even if you corrected the format, you would still have the problem that Safari's implementation of parsing times without timezones is wrong (i.e. not according to the specification).

new Date('2019-11-15 10:06'); // DO NOT USE: fails in Safari

Therefore it is better to stick with your stringToDate function to create date objects.

Answer 3

You have answered your question:

I wonder if it would be more performant and or more reliable if I would just rely on [the built–in parser] to do it for me…

I am aware the Date [parsers] behave differently according to browser…

So you already know that using the built–in parser is unreliable.

There are only two formats supported by ECMA-262, and at least one current browser fails to parse one of them, and older browsers that also fail. So your choices are:

1. Use a simple function to parse a specific format string where you are certain of the result
2. Use a library and parser where you supply the format to parse and are again certain of the result
3. Hope that whatever implementation runs your code happens to parse it correctly on the basis that the couple of browsers you tried did so, ignoring the huge number of other existing and future implementations that might run your code

Not really a hard choice.