Recently at work we moved our iOS React Native app from JSC to Hermes which became available for iOS as of RN0.64. Previously we were using Hermes only on Android and it was working great. Now that Android and iOS run the same engine we have confidence that our JavaScript output for both platforms will be equal – they should work and fail in JS land in the same ways.
One thing which immediately broke on iOS was our Apple Health integration (which of course is iOS only) – specifically when parsing dates for user activities on the JS side. The date string returned from Objective-C to JavaScript looks like this:
2021-08-31T17:00:00.000+0300
We could parse this previously on JSC using new Date() but for some reason it results in an "Invalid Date" on Hermes. Turns out the problem was in the time zone offset. Hermes could only parse ISO dates containing a time zone offset in ±HH:mm format:
+03:00
but not in a format without a colon ±HHmm:
+0300
Reading about ISO 8601, it seems that both formats would be correct. I've submitted an issue about this on facebook/hermes to get more information and apparently JavaScript implements a simplified version of ISO 8601 which doesn't specify the time zone offset without a colon:
@neildhar: Hi @osamaqarem, thanks for reporting this. Note that the JavaScript uses a simplified version of ISO 8601, and does not specify the format without the colon for the timezone. However, as you mentioned, most other engines seem to support it, so we probably should too.
So until this gets fixed in Hermes we will need to implement a workaround. We used the custom date formatter from Day.js – a great library which we were already making use of in our codebase.
Parsing Custom Dates
Day.js depends on new Date() for parsing under the hood. Meaning it would still fail to parse our date when running Hermes. A small bundle size is one of the main features of Day.js so the package ships with only core functionality. To extend its capabilities, we use plugins. And the one we need is CustomParseFormat:
import dayjs from "dayjs"
import customParseFormat from "dayjs/plugin/customParseFormat"
dayjs.extend(customParseFormat)
That's it! Quite straightforward.
Now we just need to define our format. To give Dayjs the ability to parse our date, we need to tell it what our date looks like based on these defined formats, e.g.:
| Format | Output | Description |
|---|---|---|
YY |
18 | Two-digit year |
YYYY |
2018 | Four-digit year |
M |
1-12 | The month, beginning at 1 |
MM |
01-12 | The month, 2-digits |
D |
1-31 | The day of the month |
DD |
01-31 | The day of the month, 2-digits |
H |
0-23 | The hour |
HH |
00-23 | The hour, 2-digits |
m |
0-59 | The minute |
mm |
00-59 | The minute, 2-digits |
ss |
00-59 | The second, 2-digits |
SSS |
000-999 | The millisecond, 3-digits |
Z |
+05:00 | The offset from UTC, ±HH:mm |
ZZ |
+0500 | The offset from UTC, ±HHmm |
You can find the full reference here.
Our date looks like 2021-08-31T17:00:00.000+0300, so the format we need would be:
'T' here is a constant which would be present in the expected date string
YYYY-MM-DDTHH:mm:ss.SSSZZ
Using our custom format:
dayjs("2021-08-31T17:00:00.000+0300", "YYYY-MM-DDTHH:mm:ss.SSSZZ").toISOString()
// 2021-08-31T14:00:00.000Z
That works! And once the fix for Hermes is in, we can replace it with a regular JS date constructor call.
Check out the source code for CustomParseFormat.
This article was cross-posted from my personal blog. Do subscribe to me there!
Top comments (1)
Would totally go for that if we weren’t using Dayjs already. But oh man I’m so bad at regex I think it would take me ages to come up with that expression. Thanks for the tip 😁