ทำไมการลบสองครั้งนี้ (ในปี 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(อย่างที่ฉันคาดหวังจากความแตกต่างหนึ่งวินาทีในเวลา) แต่353?

หากฉันเปลี่ยนวันที่เป็นเวลา 1 วินาทีในภายหลัง:

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

จากนั้นจะเป็นld4-ld31

รุ่น 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

มันเป็นการเปลี่ยนแปลงเขตเวลาในวันที่ 31 ธันวาคมในเซี่ยงไฮ้

ดูหน้านี้สำหรับรายละเอียดของปี 1927 ในเซี่ยงไฮ้ โดยทั่วไปเวลาเที่ยงคืนในตอนท้ายของ 2470 นาฬิกากลับไป 5 นาที 52 วินาที ดังนั้น "1927-12-31 23:54:08" จึงเกิดขึ้นจริงสองครั้งและดูเหมือนว่า Java กำลังแยกวิเคราะห์ว่าเป็นช่วงเวลาที่เป็นไปได้ในภายหลังสำหรับวันที่ / เวลาท้องถิ่นดังนั้นจึงมีความแตกต่าง

แค่อีกตอนหนึ่งในโลกที่แปลกประหลาดและมหัศจรรย์ของเขตเวลา

แก้ไข:หยุดกด! การเปลี่ยนแปลงประวัติศาสตร์ ...

คำถามเดิมจะไม่แสดงให้เห็นถึงพฤติกรรมที่ค่อนข้างเดียวกันถ้าสร้างขึ้นมาใหม่กับรุ่น 2013a ของTZDB ในปี 2013a ผลลัพธ์จะเป็น 358 วินาทีโดยมีช่วงการเปลี่ยนภาพ 23:54:03 แทนที่จะเป็น 23:54:08

ฉันสังเกตเห็นเพียงเพราะฉันรวบรวมคำถามเช่นนี้ใน Noda Time ในรูปแบบของการทดสอบหน่วย ... ตอนนี้การทดสอบเปลี่ยนไป แต่มันก็แสดงให้เห็น - ไม่ใช่แม้แต่ข้อมูลในอดีตที่ปลอดภัย

แก้ไข:ประวัติมีการเปลี่ยนแปลงอีกครั้ง ...

ใน TZDB 2014f เวลาของการเปลี่ยนแปลงได้ย้ายไปที่ 1900-12-31 และตอนนี้เปลี่ยนเป็นเพียง 343 วินาที (ดังนั้นเวลาระหว่างtและt+1344 วินาทีถ้าคุณเห็นสิ่งที่ฉันหมายถึง)

แก้ไข:เพื่อตอบคำถามเกี่ยวกับช่วงการเปลี่ยนภาพที่ 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ถือว่าเป็นแนวคิดที่ถูกต้อง) ดังนั้นห้องสมุดอื่น ๆ ไม่จำเป็นต้องแนะนำการเปลี่ยนแปลงประดิษฐ์นี้

คุณประสบความไม่ต่อเนื่องตามเวลาท้องถิ่น :

เมื่อเวลามาตรฐานท้องถิ่นใกล้จะถึงวันอาทิตย์ที่ 1 มกราคม 1928, 00:00:00 นาฬิกาหันหลังกลับ 0:05:52 ชั่วโมงถึงวันเสาร์ที่ 31 ธันวาคม 1927, 23:54:08 เวลามาตรฐานท้องถิ่นแทน

นี่ไม่ใช่เรื่องแปลกโดยเฉพาะและเกิดขึ้นได้ทุกที่ในเวลาเดียวเนื่องจากโซนเวลาถูกเปลี่ยนหรือเปลี่ยนแปลงเนื่องจากการดำเนินการทางการเมืองหรือการบริหาร

คุณธรรมของความแปลกประหลาดนี้คือ:

• ใช้วันที่และเวลาใน UTC หากทำได้
• หากคุณไม่สามารถแสดงวันที่หรือเวลาใน UTC ได้ให้ระบุเขตเวลาเสมอ
• หากคุณไม่สามารถกำหนดวันที่ / เวลาอินพุตใน UTC ได้ต้องระบุโซนเวลาอย่างชัดเจน

เมื่อเวลาเพิ่มขึ้นคุณควรแปลงกลับเป็น UTC จากนั้นเพิ่มหรือลบ ใช้เวลาท้องถิ่นเท่านั้นสำหรับการแสดงผล

วิธีนี้คุณจะสามารถเดินผ่านช่วงเวลาใดก็ได้ที่มีชั่วโมงหรือนาทีเกิดขึ้นสองครั้ง

หากคุณแปลงเป็น UTC ให้เพิ่มในแต่ละวินาทีและแปลงเป็นเวลาท้องถิ่นเพื่อให้แสดง คุณจะต้องผ่านเวลา 11:54:08 น. LMT - 23:59:59 น. LMT แล้ว 11:54:08 น. CST - 23:59:59 น. CST

แทนการแปลงแต่ละวันคุณสามารถใช้รหัสต่อไปนี้:

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

แล้วดูว่าผลลัพธ์คือ:

1

ฉันขอโทษที่จะพูด แต่เวลาไม่ต่อเนื่องได้ขยับเข้ามาเล็กน้อย

JDK 6สองปีที่ผ่านมาและในJDK 7เพิ่งในการปรับปรุง 25

บทเรียนที่จะเรียนรู้: หลีกเลี่ยงเวลาที่ไม่ได้อยู่ในค่าใช้จ่ายทั้งหมดยกเว้นอาจจะแสดง

ตามที่อธิบายโดยผู้อื่นมีเวลาไม่ต่อเนื่องที่นั่น มีสองชดเชยเขตเวลาที่เป็นไปได้สำหรับการ1927-12-31 23:54:08ที่แต่เพียงหนึ่งชดเชยสำหรับAsia/Shanghai 1927-12-31 23:54:07ดังนั้นขึ้นอยู่กับว่าใช้ออฟเซ็ตใดมีความแตกต่างหนึ่งวินาทีหรือ 5 นาทีและ 53 วินาที

การเปลี่ยนแปลงเล็กน้อยของการชดเชยนี้แทนที่จะใช้การประหยัดเวลากลางวันหนึ่งชั่วโมงปกติ (ฤดูร้อน) ที่เราคุ้นเคยเพื่อบดบังปัญหาเล็กน้อย

โปรดทราบว่าการอัปเดตฐานข้อมูลของเขตเวลา 2013a ย้ายความไม่ต่อเนื่องนี้เมื่อไม่กี่วินาทีก่อนหน้านี้ แต่ผลจะยังคงสังเกตได้

java.timeแพคเกจใหม่บน Java 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());

จากนั้นdurationAtEarlierOffsetจะเป็นหนึ่งวินาทีในขณะที่durationAtLaterOffsetจะเป็นห้านาทีและ 53 วินาที

นอกจากนี้ offsets สองแบบนี้เหมือนกัน:

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

คุณสามารถตรวจสอบว่าการเปลี่ยนแปลงเป็นที่ทับซ้อนกันที่มีมากกว่าหนึ่งที่ถูกต้องชดเชยสำหรับวันที่ / เวลาหรือช่องว่างที่วันที่ / เวลาที่ไม่ถูกต้องสำหรับ ID โซนนั้น - โดยการใช้isOverlap()และวิธีการเกี่ยวกับisGap()zot4

ฉันหวังว่าสิ่งนี้จะช่วยให้ผู้ใช้จัดการกับปัญหาประเภทนี้ได้เมื่อ Java 8 พร้อมใช้งานอย่างกว้างขวางหรือสำหรับผู้ที่ใช้ Java 7 ซึ่งใช้ backport JSR 310

IMHO การโลคัลไลเซชั่นที่แพร่หลายและเป็นนัยใน Java คือข้อบกพร่องด้านการออกแบบที่ใหญ่ที่สุด อาจมีไว้สำหรับส่วนต่อประสานกับผู้ใช้ แต่ตรงไปตรงมาผู้ใช้ Java สำหรับส่วนต่อประสานผู้ใช้จริงๆในวันนี้ยกเว้น IDEs บางตัวที่คุณสามารถละเว้นการโลคัลไลซ์เซชันได้เนื่องจากโปรแกรมเมอร์ไม่ได้เป็นกลุ่มเป้าหมายโดยตรง คุณสามารถแก้ไขได้ (โดยเฉพาะบนเซิร์ฟเวอร์ Linux) โดย:

• ส่งออก LC_ALL = C TZ = UTC
• ตั้งค่านาฬิการะบบของคุณเป็น UTC
• ไม่ใช้การใช้งานที่แปลเป็นภาษาท้องถิ่นเว้นแต่จำเป็นจริงๆ (เช่นเพื่อแสดงเท่านั้น)

สำหรับสมาชิกJava Community Processฉันแนะนำ:

• ทำให้วิธีการแปลไม่ใช่ค่าเริ่มต้น แต่ต้องการให้ผู้ใช้ร้องขอการแปลอย่างชัดเจน
• ใช้ UTF-8 / UTC เป็นค่าเริ่มต้นคงที่เนื่องจากเป็นเพียงค่าเริ่มต้นในวันนี้ ไม่มีเหตุผลที่จะทำอย่างอื่นยกเว้นถ้าคุณต้องการสร้างเธรดเช่นนี้

ฉันหมายถึงมาไม่ตัวแปรคงที่ทั่วโลกเป็นรูปแบบการต่อต้าน OO? ไม่มีอะไรอื่นเป็นค่าเริ่มต้นที่แพร่หลายที่กำหนดโดยตัวแปรสภาพแวดล้อมพื้นฐานบางอย่าง .......

อย่างที่คนอื่นพูดกันมันเปลี่ยนเวลาในปี 1927 ในเซี่ยงไฮ้

เมื่อมันเป็น23:54:07ในเซี่ยงไฮ้, เวลามาตรฐานท้องถิ่น แต่หลังจาก 5 นาทีและ 52 วินาทีก็หันไปในวันถัดไปที่แล้วเวลามาตรฐานท้องถิ่นเปลี่ยนกลับไปเป็น00:00:00 23:54:08นั่นคือสาเหตุที่ความแตกต่างระหว่างสองครั้งคือ 343 วินาทีไม่ใช่ 1 วินาทีอย่างที่คุณคาดไว้

เวลาสามารถทำให้สับสนในที่อื่น ๆ เช่นสหรัฐอเมริกา สหรัฐอเมริกามีการปรับเวลาตามฤดูกาล เมื่อเวลาออมแสงเริ่มขึ้นเวลาจะไปข้างหน้า 1 ชั่วโมง แต่หลังจากนั้นครู่หนึ่งเวลาปรับเวลาตามฤดูกาลสิ้นสุดลงและจะย้อนกลับไป 1 ชั่วโมงกลับไปที่โซนเวลามาตรฐาน ดังนั้นบางครั้งเมื่อเปรียบเทียบเวลาในสหรัฐอเมริกาความแตกต่างคือประมาณ3600ไม่กี่วินาที

แต่มีบางอย่างที่แตกต่างกันเกี่ยวกับการเปลี่ยนแปลงสองครั้งนี้ การเปลี่ยนแปลงหลังอย่างต่อเนื่องและอดีตเป็นเพียงการเปลี่ยนแปลง มันไม่ได้เปลี่ยนกลับหรือเปลี่ยนแปลงอีกครั้งในจำนวนเดียวกัน

จะเป็นการดีกว่าถ้าใช้ UTC โดยที่เวลาไม่เปลี่ยนแปลงหากจำเป็นต้องใช้เวลาที่ไม่ใช่เวลา UTC เช่นในการแสดงผล