This is the first log of my open source contributions. Created for myself, somewhat inspired by the paper “The Errors of TeX” by Donald Knuth.

Own Projects

Not much to report here. For my own little TypeScript project picofp there is a dependabot alert that I’ve just not gotten to yet.

Started a new project that should become public as soon as I get a MVP going.

Firefox

I’ve finally found the time to start contributing to firefox again. Hitting my own little hobby horse date parsing. The basic story of javascript date parsing is “Try to parse the date as an ISO-8601 date and if that fails to whatever you want.. I don’t care”. Which means a lot of bugs (date parsing is of course hard) and a lot of incompatibility bugs (chrome parses a lot of formats).

I started working on two bugs to ease myself into firefox development again and make sure I remember the old stuff and learn the new ways of working.

Bug: 1328672

A bug concerning the timezone offset in date parsing. Firefox allows four digits for the timezone offset. Either with a : character between the second and the third number of just straight four numbers. We also allow dates to separate the date and the time part with a instead of a T character.

That means we supported dates like:

2016-12-29 08:30:14-0700
2016-12-29 08:30:14-07:00

What we didn’t support were dates on the form 2016-12-29 08:30:14-07 where the timezone offset is just two digits. This is something both chrome and edge supports which makes it a good target for compatibility. Another wrinkle in the bug is that they only allow this for when the supplied date have exchanged the T character with a as mentioned above. The simple fix was to see if we had reached the end of the string when we had parsed two digits of the timezone offset.

Link to the diff in the date parser: https://hg.mozilla.org/mozilla-central/diff/042937e67e03b88d80ff764cb10df041820e7855/js/src/jsdate.cpp

Bug: 802750

Another date parsing bug. This time we are not spec compliant. The spec says that we are allowed to represent years in an expanded format with six digits, this is in order to be able to represent the full range of years allowed in the spec (plus minus 273,790 years from the UNIX epoch). Expanded years are always prefixed with either + or - and the year 000000 is always positive and must therefore be written as +000000. We allowed the date -000000 which is not spec compliant.

This was also an easy change. Make sure that if we have seen an - and the year is 0 then we simply return NaN (signifying an invalid date).

At the time of writing this change has not been reviewed or merged.

WHATWG

I’ve wanted to get into working on some web specifications and did a small little change in the WHATWG Streams standard (https://github.com/whatwg/streams). Barely worth mentioning given that it was mostly a “get to know how to contribute” to the specs and all that goes around it. There was an argument in the specification to a function that was not needed and not used anywhere.

Link to changeset: https://github.com/whatwg/streams/commit/5d86b65e45e0d56fcb8fbbff52fbbf2394918154