I discovered an odd browser issue. In Safari (which my iPhone tells me is updated), I am getting
0 as a value for some calculated cells (not others). This notebook only uses filter and group. Viewing the notebook with Android, Linux, and Windows versions of Chrome, Chromium and Firefox, all is good.
This notebook provides an example:
The problem is that the date format you pass to
Date.parse() cannot be processed by Safari. If you change it to, e.g., “2019-06-30” Safari will be able to process it as well.
Crazy! Is this error is also related to Safari and
I can’t remember if I used added
d3-time-format to account the many ways dates were formatted in my source data, or if I just wanted a sane way to write dates, b/c I keep messing up dates due to months sometimes being offset by 1 in JS.
… Ah, I now remember it as something about
Date.parse() returning unexpected values:
Date.parse(2018, 7, 1) = 1514764800000
Date.parse('2018-07-01') = 1530403200000
Date.parse('2018-July-01') = 1530417600000
Somehow the explicit month names corrected for this.
You should only use Date.parse or the Date constructor to parse strings if you stick to the ECMAScript date time format as described here, which is closely related to ISO 8601:
So for dates (without times), only use YYYY-MM-DD. If you’re using anything else, you should use a date parser such as d3-time-format’s d3.timeParse or d3.utcParse, or else you risk differing behavior across browsers.
(Also, if you require d3@5, there’s no reason to also require d3-time-format, since d3-time-format is already bundled into d3 at the same version. The d3-array@2 require is just a temporary thing until d3@6 is released.)
d3.timeParse to the rescue! Thanks Mike!