y10k | Automate your Yum package mirrors with ease

ISO 8601 does permit this year format. From Wikipedia:

To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver. An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign instead of the more common AD/BC (or CE/BCE) notation;

However, since it only permits this "by prior agreement between the sender and the receiver", it is quite strange that adding the sign is the default behaviour of LocalDate.toString.

According to the docs:

Year: The count of letters determines the minimum field width below which padding is used. If the count of letters is two, then a reduced two digit form is used. For printing, this outputs the rightmost two digits. For parsing, this will parse using the base value of 2000, resulting in a year within the range 2000 to 2099 inclusive. If the count of letters is less than four (but not two), then the sign is only output for negative years as per SignStyle.NORMAL. Otherwise, the sign is output if the pad width is exceeded, as per SignStyle.EXCEEDS_PAD.

So if you don't want the sign, you can use 3 "y"s, or just 1 "y", since 3 and 1 are both "less than four (but not two)".

Also, since "y" means "year of era", there won't be any negative years, so you don't need to worry about it outputting a sign for negative years either.

Example: