Handle time-range start & end string that contain timezone postfixes like +00:00

[emrysal]

Currently when configuring a time-range it handles converting a ISO8601 time string to a ISO8601 time string without seperators, this works pretty well:

timeRange?.start.replace(/[-:.]/g, '')

// "2018-10-17T20:49:00Z".replace(/[-:.]/g, "")
// "20181017T204900Z" = neat

Based on which Date library or formatting you use however, I believe there are a couple of valid isodate strings that this library should support:

• 2018-10-17T20:49:00+00:00 (Long form UTC, I believe this should auto-convert to Z) - currently this becomes the invalid string: 20181017T204900+0000.
• 2018-10-17T20:49:00+08:00 (Local time, must not be used rfc5545) - currently becomes 20181017T204900+0800. My thoughts are this should strip the +0800 part OR maybe even throw an error that the user passed a non-UTC timestamp.

👍 Great library - willing to help contribute the above, let me know what you think.

[natelindev]

What I recommend doing is to use Date object, or whatever datetime libraries that have toISOString() function and pass the result here instead of using raw timeString. Since this is not a datetime library, I'm not quite willing to add too much datetime logic.

[emrysal]

I can agree with that; however changing the string out for a date would be a breaking change - in addition you'd still need to postprocess toISOString() to get valid input.

// note, regex unmerged for clarity - removes milliseconds and seperator characters.
date.toISOString().replace(/\.[0-9]{3}/, '').replace(/[-:.]/g, '')

// potential implementation:
timeRange?.start.toISOString().replace(/(\.[0-9]{3}|[-:.])/g, '')

[natelindev]

All ISO8601 should be supported in v1.1.0 now, and non-ISO8601 format will cause an error be thrown. Since time range is now validated.