Executando verificação de segurança...
Em resposta a Indicador do Século
2

Só pra complementar a outra resposta (que já deu a solução mais sucinta que posso pensar, mas acho que vale o complemento):

Por que o ano é um array contendo uma string? Tem algum requisito/condição para isso?

De qualquer forma, isso só funcionou porque o JavaScript tem algumas "mágicas" que acontecem por debaixo dos panos. Se vc tenta usar qualquer objeto em um contexto numérico, primeiro ele é convertido para número. As regras - bem complicadas, por sinal - estão descritas na especificação da linguagem.

Mas de forma bem resumida, um array primeiro é convertido para "primitivo", que no caso gera uma string contendo seus elementos separados por vírgula. Então quando o array só tem um elemento e este é uma string, o resultado é esta string, que depois é convertida para número. Por isso "funciona". Mas se eu passar um array com dois elementos, ou qualquer outra coisa (como a string "xyz"), não funciona mais.

Enfim, não ficou claro se a ideia era também validar o ano antes de calcular o século. Se não for, então a solução do Maniero é a mais simples e direto ao ponto. Mas se tiver que validar, poderia ser:

function getCentury(year) {
    return Math.ceil(parseInt(year) / 100);
}

let year = ["1900"];
let century = getCentury(year);
// verificar o retorno
if (isNaN(century)) {
    console.log('Ano inválido, não foi possível obter o século'); // mude para uma mensagem melhor
} else {
    console.log(century);
}

Agora se eu passar algo como "xyz", vai indicar que o ano é inválido.

Se bem que, caso year seja um número, não tem porque converter, então para ser mais preciosista, poderia ser:

function getCentury(year) {
    if (typeof year !== 'number')
        year = parseInt(year);
    return Math.ceil(year / 100);
}

Claro, também poderia verificar dentro da função, mas aí ela teria que retornar algo para indicar que deu erro, e quem a chamou precisaria verificar isso. É outra alternativa, mas o "melhor" depende de cada caso, dos requisitos e outras informações que não temos. Por ora, deixemos assim mesmo.

Ou então vc só tenta fazer o cálculo direto mesmo, e deixa para as regras de coerção da linguagem converterem. Eu particularmente não gosto, pois prefiro deixar claro o que a operação espera - ao usar parseInt, por exemplo, sinalizo que deve ser um número inteiro. "Vai ficar com menos linhas" não é uma boa justificativa para retirar uma validação (ou qualquer outra coisa que deixe o código mais claro e semântico).


E reforçando o que foi dito sobre ponto-e-vírgula no final das linhas: pode parecer "frescura", e sei que o JavaScript "aceita" o código sem ponto e vírgula e "funciona", mas isso evita algumas situações bizarras que podem ocorrer se você não usá-los, como essa e essa (veja mais sobre isso aqui).

Carregando publicação patrocinada...