왜이 두 번 빼기 (1927 년)가 이상한 결과를 낳습니까?

다음 프로그램을 실행하면 시간을 1 초 간격으로 참조하는 두 개의 날짜 문자열을 구문 분석하고 비교합니다.

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);
}

출력은 다음과 같습니다.

353

왜 ld4-ld3하지 1(나는 시간에 1 초 차이에서 기대하는 것처럼), 그러나 353?

1 초 후에 날짜를 시간으로 변경하면 :

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

그러면 ld4-ld3됩니다 1.

자바 버전 :

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

12 월 31 일 상하이에서 시간대가 변경되었습니다.

1927 년 상하이에 대한 자세한 내용은 이 페이지 를 참조하십시오 . 기본적으로 1927 년 말 자정에 시계는 5 분 52 초로 되돌아갔습니다. 따라서 "1927-12-31 23:54:08"은 실제로 두 번 발생했으며 Java가 현지 날짜 / 시간에 대해 나중에 가능한 순간 으로 구문 분석하는 것처럼 보이 므로 차이가 있습니다.

종종 이상하고 멋진 시간대의 세계에서 또 다른 에피소드.

편집 : 보도 중지! 역사 변경 ...

TZDB 버전 2013a로 다시 빌드하면 원래 질문은 더 이상 똑같은 동작을 나타내지 않습니다 . 2013a에서 결과는 358 초이며 전환 시간은 23:54:08 대신 23:54:03입니다.

단위 테스트 형태로 Noda Time에서 이와 같은 질문을 수집하기 때문에이 사실을 알았습니다 ... 테스트는 이제 변경되었지만 표시됩니다. 이력 데이터조차도 안전하지 않습니다.

편집 : 역사가 다시 변경되었습니다 ...

TZDB 2014 년, 변화의 시간이 1900년 12월 31일로 이동하고 있으며, (사이의 시간, 그래서 지금은 단순한 343초 변화의 t및 t+13백44초 당신이 무슨 뜻인지 볼 경우).

편집 : 1900에서 전환에 관한 질문에 대답하기 위해 ... Java 시간대 구현은 모든 시간대를 단순히 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);
            }
        }
    }
}

위의 코드는 Windows 컴퓨터에서 출력을 생성하지 않습니다. 따라서 1900 년 시작시 표준 시간대 이외의 오프셋이있는 시간대는 전환으로 간주합니다. TZDB 자체는 그보다 이전에 돌아가는 일부 데이터를 가지고 있으며 "고정 된"표준 시간 ( getRawOffset유효한 개념이라고 가정) 에 대한 아이디어에 의존하지 않으므로 다른 라이브러리는이 인공적인 전환을 도입 할 필요가 없습니다.

현지 시간 불연속 이 발생했습니다 .

1928 년 1 월 1 일 일요일 오전 10시 00 분 00 초에 도달하려고했을 때, 시계는 0:05:52 시간에서 0:05:52 시간으로 되돌아갔습니다. 1927 년 12 월 31 일 23:54:08

이것은 특별히 이상하지는 않으며 정치적 또는 행정적 조치로 시간대가 바뀌거나 바뀌면서 한 번에 거의 모든 곳에서 발생했습니다.

이 이상의 도덕은 다음과 같습니다.

• 가능하면 UTC로 날짜와 시간을 사용하십시오.
• 날짜 또는 시간을 UTC로 표시 할 수없는 경우 항상 시간대를 표시하십시오.
• UTC로 입력 날짜 / 시간을 요구할 수없는 경우 명시 적으로 표시된 시간대를 요구하십시오.

시간이 증가하면 UTC로 다시 변환 한 다음 더하거나 빼야합니다. 현지 시간 만 표시하십시오.

이렇게하면 몇 시간 또는 몇 분이 두 번 발생하는 기간을 걸을 수 있습니다.

UTC로 변환 한 경우 1 초마다 추가하고 표시 할 현지 시간으로 변환하십시오. LMT 오후 11:54:08 (오후 LMT -11:59:59), LST 오후 11:54:08 ( CST -11:59:59) CST 를 거칩니다 .

각 날짜를 변환하는 대신 다음 코드를 사용할 수 있습니다.

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

그리고 결과는 다음과 같습니다.

1

죄송 합니다만 시간 불연속이 조금 바뀌 었습니다.

JDK 6 2 년 전, JDK 7 에서 최근 업데이트 25 .

배우는 교훈 : 디스플레이를 제외하고 모든 비용으로 비 UTC 시간을 피하십시오.

다른 사람들이 설명했듯이 시간 불연속이 있습니다. 1927-12-31 23:54:08at Asia/Shanghai에 대해 두 개의 가능한 시간대 오프셋이 있지만에 대한 하나의 오프셋 만 1927-12-31 23:54:07있습니다. 따라서 어떤 오프셋이 사용되는지에 따라 1 초 차이 또는 5 분 53 초 차이가 있습니다.

우리가 익숙한 일반적인 1 시간 일광 절약 시간 (서머 타임) 대신이 약간의 오프셋 이동은 문제를 조금 가려줍니다.

시간대 데이터베이스의 2013a 업데이트는 몇 초 전에이 불연속성을 옮겼지만 그 효과는 여전히 관찰 가능합니다.

java.timeJava 8 의 새로운 패키지를 사용하면이를보다 명확하게보고 처리 할 수있는 도구를 제공 할 수 있습니다. 주어진:

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());

그러면 durationAtEarlierOffset1 durationAtLaterOffset초가되고 5 분 53 초가됩니다.

또한이 두 오프셋은 동일합니다.

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

그러나이 두 가지는 다릅니다.

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

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

동일한 문제가 비교 볼 수 있습니다 1927-12-31 23:59:59으로 1928-01-01 00:00:00하지만,이 경우는 이전에 더 이상 차이를 생산하는 오프셋, 그것은 두 가지 오프셋을 가지고 이전 날짜입니다.

이에 접근하는 또 다른 방법은 전환이 진행 중인지 확인하는 것입니다. 우리는 이렇게 할 수 있습니다 :

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

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

에서 isOverlap()및 isGap()메소드를 사용하여 전환이 해당 날짜 / 시간에 대해 유효한 오프셋이 둘 이상인 경우 겹침인지 또는 해당 날짜 / 시간이 해당 영역 ID에 대해 유효하지 않은 간격인지 확인할 수 있습니다 zot4.

Java 8이 널리 사용 가능해 지거나 JSR 310 백 포트를 채택한 Java 7을 사용하는 사람들이 이런 종류의 문제를 처리하는 데 도움이되기를 바랍니다.

Java에서 널리 사용되는 암시 적 현지화는 단일 설계상의 가장 큰 결함입니다. 사용자 인터페이스를위한 것일 수도 있지만, 솔직히 말해서 프로그래머가 타겟 대상이 아니기 때문에 기본적으로 지역화를 무시할 수있는 일부 IDE를 제외하고 오늘날 사용자 인터페이스에 Java를 실제로 사용하는 사용자는 있습니다. 다음을 통해 문제를 해결할 수 있습니다 (특히 Linux 서버에서).

• 수출 LC_ALL = C TZ = UTC
• 시스템 시계를 UTC로 설정
• 반드시 필요한 경우가 아니면 현지화 된 구현을 사용하지 마십시오 (예 : 디스플레이 전용).

받는 자바 커뮤니티 프로세스의 회원 나는 추천 :

• 현지화 된 메소드를 기본값으로 설정하지 말고 사용자에게 명시 적으로 현지화를 요청해야합니다.
• UTF-8 / UTC를 FIXED 기본값으로 대신 사용하십시오. 이것이 오늘날의 기본값이기 때문입니다. 이와 같은 스레드를 생성하려는 경우를 제외하고는 다른 작업을 수행 할 이유가 없습니다.

전역 정적 변수가 anti-OO 패턴이 아닙니까? 다른 기본 환경 변수에 의해 제공되는 광범위한 기본값은 없습니다.

다른 사람들이 말했듯이 1927 년 상하이에서 시간이 바뀌 었습니다.

이 때 23:54:07상하이, 로컬 표준 시간에, 그러나 오분 52 초 후에, 그것의 다음날로 전환 00:00:00한 다음 로컬 표준 시간으로 다시 변경 23:54:08. 그래서 두 시간의 차이가 예상했던 것처럼 1 초가 아닌 343 초입니다.

미국과 같은 다른 곳에서도 시간이 엉망이 될 수 있습니다. 미국에는 일광 절약 시간 제가 있습니다. 일광 절약 시간 제가 시작되면 시간이 1 시간 앞으로 이동합니다. 그러나 잠시 후 일광 절약 시간이 종료되고 표준 시간대로 1 시간 뒤로 이동합니다. 따라서 미국에서 시간을 비교할 때 차이는 36001 초가 아닌 약 초입니다.

그러나이 두 시간 변화에는 다른 점이 있습니다. 후자는 지속적으로 변화하고 전자는 단지 변화 일뿐입니다. 같은 양만큼 변경되거나 다시 바뀌지 않았습니다.

UTC가 아닌 시간을 디스플레이와 같이 사용해야하는 경우가 아니면 시간이 변경되지 않는 UTC를 사용하는 것이 좋습니다.