Não intencional - na verdade, prefiro um formato DDMMAAAA mais claro, embora AAAAMMDD também seja aceitável.

YYYYMMDD tem a vantagem de ser ordenado lexicograficamente. Classifique as strings desse formato em ordem lexicográfica crescente e você também as obtém em ordem cronológica crescente gratuitamente.

Ponto justo

Parece que isso deve ser corrigido em # 450?

Isso foi corrigido antes, mas o fluxo de construção mudou drasticamente e não tenho certeza de onde está a fonte do padrão YYYYDDMM (# 450 é direcionado a um branch que não está (ainda?) Sendo usado, tanto quanto posso dizer )

Isso só deve acontecer com o SDK OpenJDK8_aarch64_Linux_ * , já que a tarefa de construção openjdk8_build_aarch64_linux está configurada de forma diferente. https://ci.adoptopenjdk.net/job/openjdk8_build_aarch64_linux/configure . Isso quer dizer que esta construção não usa a história de construção do openjdk-build (embora eu não saiba por quê). Eu atualizei o shell de execução para

`` `# waring valores codificados e mudanças incompatíveis cross-jdk
somente leitura TIMESTAMP = "$ (data + '% Y% m% d% H% M')"

versão principal codificada e plataforma (arquitetura e sistema operacional)

`` `
O que deve resolver este problema.
O ideal é definir o parâmetro do trabalho TIMESTAMP.

Aarch64 jdk8 de hoje: OpenJDK8_aarch64_Linux_201808301146.tar.gz. Outros também parecem bons, bom fechar isso por agora. (não percebi que não tenho permissão, @karianna poderia fechá-lo?)