Por que subtrair essas duas vezes (em 1927) está dando um resultado estranho?

Se eu executar o programa a seguir, que analisa duas seqüências de datas fazendo referência a tempos com um segundo de diferença e as compara:

public static void main(String[] args) throws ParseException {
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  
    String str3 = "1927-12-31 23:54:07";  
    String str4 = "1927-12-31 23:54:08";  
    Date sDt3 = sf.parse(str3);  
    Date sDt4 = sf.parse(str4);  
    long ld3 = sDt3.getTime() /1000;  
    long ld4 = sDt4.getTime() /1000;
    System.out.println(ld4-ld3);
}

A saída é:

353

Por que ld4-ld3não é 1(como eu esperaria da diferença de um segundo nos tempos), mas 353?

Se eu alterar as datas para horários 1 segundo depois:

String str3 = "1927-12-31 23:54:08";  
String str4 = "1927-12-31 23:54:09";  

Então ld4-ld3será 1.

Versão Java:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)

Timezone(`TimeZone.getDefault()`):

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

Locale(Locale.getDefault()): zh_CN

É uma mudança de fuso horário no dia 31 de dezembro em Xangai.

Veja esta página para detalhes de 1927 em Xangai. Basicamente, à meia-noite do final de 1927, os relógios retrocederam 5 minutos e 52 segundos. Então "1927-12-31 23:54:08" realmente aconteceu duas vezes, e parece que o Java está analisando-o mais tarde instante possível para a data / hora local - daí a diferença.

Apenas mais um episódio no mundo muitas vezes estranho e maravilhoso dos fusos horários.

EDIT: Pare de pressionar! O histórico muda ...

A pergunta original não demonstraria mais o mesmo comportamento, se reconstruída com a versão 2013a do TZDB . Em 2013a, o resultado seria 358 segundos, com um tempo de transição de 23:54:03 em vez de 23:54:08.

Eu só notei isso porque estou coletando perguntas como essa no Noda Time, na forma de testes de unidade ... O teste agora foi alterado, mas é apenas para mostrar - nem mesmo dados históricos são seguros.

EDIT: História mudou novamente ...

No TZDB 2014f, o tempo da mudança mudou para 1900-12-31, e agora é apenas uma mudança de 343 segundos (portanto, o tempo entre te t+1é 344 segundos, se você entende o que eu quero dizer).

EDIT: Para responder a uma pergunta sobre uma transição em 1900 ... parece que a implementação do fuso horário Java trata todos os fusos horários como estando simplesmente no horário padrão por qualquer instante antes do início de 1900 UTC:

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}

O código acima não produz resultados na minha máquina Windows. Portanto, qualquer fuso horário que possua outro deslocamento que não seja o padrão no início de 1900 contará isso como uma transição. O próprio TZDB possui alguns dados voltando antes disso e não se baseia em nenhuma idéia de um tempo padrão "fixo" (que é o que getRawOffsetassume ser um conceito válido), portanto outras bibliotecas não precisam introduzir essa transição artificial.

Você encontrou uma descontinuidade na hora local :

Quando a hora local padrão estava prestes a chegar ao domingo, 1. janeiro de 1928, 00:00:00 relógios foram revertidos 0:05:52 horas para sábado, 31. dezembro 1927, 23:54:08 hora local

Isso não é particularmente estranho e aconteceu praticamente em todos os lugares ao mesmo tempo, pois os fusos horários foram trocados ou alterados devido a ações políticas ou administrativas.

A moral dessa estranheza é:

• Use datas e horas no UTC sempre que possível.
• Se você não pode exibir uma data ou hora no UTC, sempre indique o fuso horário.
• Se você não pode exigir uma data / hora de entrada no UTC, exija um fuso horário indicado explicitamente.

Ao incrementar o tempo, você deve voltar ao UTC e adicionar ou subtrair. Use a hora local apenas para exibição.

Dessa forma, você poderá percorrer todos os períodos em que horas ou minutos acontecem duas vezes.

Se você tiver convertido para UTC, adicione cada segundo e converta para a hora local para exibição. Você passaria das 23h54m - 23h59m da LMT - 23h59m59m da LMT e, em seguida, das 23:54:08 pm da CST - 23h59m59s da CST.

Em vez de converter cada data, você pode usar o seguinte código:

long difference = (sDt4.getTime() - sDt3.getTime()) / 1000;
System.out.println(difference);

E então veja que o resultado é:

1

Lamento dizer, mas a descontinuidade do tempo mudou um pouco

JDK 6 há dois anos e no JDK 7 recentemente na atualização 25 .

Lição a aprender: evite horários fora do UTC a todo custo, exceto talvez para exibição.

Como explicado por outros, há uma descontinuidade no tempo lá. Existem dois desvios de fuso horário possíveis para 1927-12-31 23:54:08at Asia/Shanghai, mas apenas um deslocamento para1927-12-31 23:54:07 . Portanto, dependendo de qual deslocamento é usado, há uma diferença de um segundo ou de 5 minutos e 53 segundos.

Essa ligeira mudança de compensações, em vez do horário de verão habitual de uma hora (horário de verão) a que estamos acostumados, obscurece um pouco o problema.

Observe que a atualização de 2013 do banco de dados de fuso horário moveu essa descontinuidade alguns segundos antes, mas o efeito ainda seria observável.

O novo java.timepacote no Java 8 permite ver isso mais claramente e fornece ferramentas para lidar com isso. Dado:

DateTimeFormatterBuilder dtfb = new DateTimeFormatterBuilder();
dtfb.append(DateTimeFormatter.ISO_LOCAL_DATE);
dtfb.appendLiteral(' ');
dtfb.append(DateTimeFormatter.ISO_LOCAL_TIME);
DateTimeFormatter dtf = dtfb.toFormatter();
ZoneId shanghai = ZoneId.of("Asia/Shanghai");

String str3 = "1927-12-31 23:54:07";  
String str4 = "1927-12-31 23:54:08";  

ZonedDateTime zdt3 = LocalDateTime.parse(str3, dtf).atZone(shanghai);
ZonedDateTime zdt4 = LocalDateTime.parse(str4, dtf).atZone(shanghai);

Duration durationAtEarlierOffset = Duration.between(zdt3.withEarlierOffsetAtOverlap(), zdt4.withEarlierOffsetAtOverlap());

Duration durationAtLaterOffset = Duration.between(zdt3.withLaterOffsetAtOverlap(), zdt4.withLaterOffsetAtOverlap());

Em seguida durationAtEarlierOffset, será um segundo, enquanto durationAtLaterOffsetserão cinco minutos e 53 segundos.

Além disso, essas duas compensações são as mesmas:

// Both have offsets +08:05:52
ZoneOffset zo3Earlier = zdt3.withEarlierOffsetAtOverlap().getOffset();
ZoneOffset zo3Later = zdt3.withLaterOffsetAtOverlap().getOffset();

Mas estes dois são diferentes:

// +08:05:52
ZoneOffset zo4Earlier = zdt4.withEarlierOffsetAtOverlap().getOffset();

// +08:00
ZoneOffset zo4Later = zdt4.withLaterOffsetAtOverlap().getOffset();

Você pode ver o mesmo problema em comparação 1927-12-31 23:59:59com 1928-01-01 00:00:00, no entanto, nesse caso, é o deslocamento anterior que produz a divergência mais longa e é a data anterior que tem duas compensações possíveis.

Outra maneira de abordar isso é verificar se há uma transição em andamento. Podemos fazer isso assim:

// Null
ZoneOffsetTransition zot3 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

// An overlap transition
ZoneOffsetTransition zot4 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

Você pode verificar se a transição é uma sobreposição em que há mais de um deslocamento válido para essa data / hora ou um intervalo em que essa data / hora não é válida para esse ID de zona - usando os métodos isOverlap()e .isGap()zot4

Espero que isso ajude as pessoas a lidar com esse tipo de problema quando o Java 8 estiver amplamente disponível ou para aqueles que usam o Java 7 que adotam o backport JSR 310.

IMHO, a localização generalizada e implícita em Java é sua maior falha de design. Pode ser destinado a interfaces de usuário, mas, francamente, quem realmente usa Java para interfaces de usuário hoje, exceto em alguns IDEs, nos quais você pode basicamente ignorar a localização porque os programadores não são exatamente o público-alvo para ela. Você pode corrigi-lo (especialmente em servidores Linux):

• exportar LC_ALL = C TZ = UTC
• ajuste o relógio do sistema para UTC
• nunca use implementações localizadas, a menos que seja absolutamente necessário (por exemplo, apenas para exibição)

Para os membros do Java Community Process , eu recomendo:

• torne os métodos localizados não o padrão, mas exija que o usuário solicite explicitamente a localização.
• use UTF-8 / UTC como o padrão FIXED, porque esse é simplesmente o padrão hoje. Não há razão para fazer outra coisa, exceto se você deseja produzir threads como este.

Quero dizer, vamos lá, as variáveis ​​estáticas globais não são um padrão anti-OO? Nada mais são os padrões generalizados dados por algumas variáveis ​​de ambiente rudimentares .......

Como outros disseram, é uma mudança de horário em 1927 em Xangai.

Quando estava 23:54:07em Xangai, o horário padrão local, mas após 5 minutos e 52 segundos, passou para o dia seguinte às 00:00:00, e o horário padrão local mudou novamente para 23:54:08. Portanto, é por isso que a diferença entre os dois tempos é de 343 segundos e não 1 segundo, como você esperaria.

O tempo também pode atrapalhar em outros lugares como os EUA. Os EUA têm horário de verão. Quando o horário de verão começa, o horário avança 1 hora. Mas, depois de um tempo, o horário de verão termina e volta 1 hora para o fuso horário padrão. Então, às vezes, ao comparar os tempos nos EUA, a diferença é de 3600segundos e não de 1 segundo.

Mas há algo diferente nessas duas mudanças de tempo. O último muda continuamente e o primeiro foi apenas uma mudança. Não mudou de volta ou mudou de novo na mesma quantidade.

É melhor usar o UTC onde o tempo não muda, a menos que seja necessário usar o horário não UTC, como no visor.