While playing with Node as someone new to JS at the time, I wrote some code to load a JSON file due to not knowing I could require it... and it was vastly less than 1000+ lines.
On a similar basis, I once worked on a codebase where someone had implemented strftime, poorly, a few different ways, and also come up with several replacements for strptime, all of which had subtle bugs and none of which worked the same.
Though strftime is in ISO C, so there is little excuse, strptime is a POSIX function, so there is at least the possibility of a credible portability argument there. (Though this probably doesn't stretch far enough to justify the lack of an #ifdef to select the system's strptime if it is provided.)
In this particular case the application was already quite POSIX-dependent in other ways, but it's a good point to make -- I did hesitate before deciding on it for that reason, now that you remind me.
To add additional details, for those who might draw amusement and/or wisdom: In all cases the input/output date/time strings had the same format. Further, a number of the bugs were due to half-implemented reinventions of atoi being involved -- and atoi was definitely available, as one of the reinventions used it! Finally, in at least one case there was a Y2100 problem.
To be fair, I'd reroll atoi too - but only once, with "sufficient" unit tests (e.g. round trip unit tests for INT_MIN..INT_MAX), and only because atoi has no proper error checking nor wchar_t* variants.
Indeed; atoi in fact invokes undefined behavior in out of range situations; you can only safely use it when the input has been lexically analyzed to be a valid integer of only so many digits as not to overflow.
I'd tend to make this re-rolled atoi a wrapper around strtol/wcstol.
On a similar basis, I once worked on a codebase where someone had implemented strftime, poorly, a few different ways, and also come up with several replacements for strptime, all of which had subtle bugs and none of which worked the same.