[Java] لماذا يتم طرح هذين المرتين (في عام 1927) لإعطاء نتيجة غريبة؟


Answers

لقد واجهت انقطاعًا للوقت المحلي :

عندما كان الوقت القياسي المحلي على وشك الوصول إلى يوم الأحد ، 1. يناير 1928 ، 00:00:00 تم تحويل الساعات إلى الوراء 0:05:52 ساعة إلى السبت 31 ديسمبر 1927 ، 23:54:08 التوقيت القياسي المحلي بدلاً من ذلك

هذا ليس غريباً على وجه الخصوص وقد حدث في كل مكان في وقتٍ أو آخر حيث تم تغيير أو تغيير المناطق الزمنية بسبب الإجراءات السياسية أو الإدارية.

Question

إذا قمت بتشغيل البرنامج التالي ، الذي يوزع اثنين من سلاسل التاريخ الرجوع إلى المرات 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 ؟

إذا قمت بتغيير التواريخ إلى ثانية واحدة في وقت لاحق:

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



عند زيادة الوقت ، يجب عليك العودة إلى التوقيت العالمي المنسق ثم إضافة أو طرح. استخدم التوقيت المحلي للعرض فقط.

بهذه الطريقة ستتمكن من المشي خلال أي فترات تحدث فيها الساعات أو الدقائق مرتين.

إذا قمت بالتحويل إلى UTC ، فأضف كل ثانية ، وقم بالتحويل إلى التوقيت المحلي للعرض. أنت ستذهب خلال 11:54:08 pm LMT - 11:59:59 مساء LMT ثم 11:54:08 pm CST - 11:59:59 pm CST.




يؤسفني أن أقول ذلك ، لكن الوقت قد توقف بعض الوقت

JDK 6 قبل عامين ، وفي JDK 7 مؤخرا في التحديث 25 .

الدرس المراد تعلمه: تجنب الأوقات غير المنسقة (UTC) بأي ثمن ، باستثناء العرض.




IMHO التوطين الضمني الواسع الانتشار في Java هو عيب التصميم الأكبر. قد يكون مخصصًا لواجهات المستخدم ، لكن بصراحة ، من يستخدم Java فعلاً لواجهات المستخدم اليوم باستثناء بعض IDEs حيث يمكنك تجاهل التعريب بشكل أساسي لأن المبرمجين ليسوا الجمهور المستهدف بالضبط. يمكنك إصلاحه (خاصة على خوادم لينكس) من خلال:

  • تصدير LC_ALL = C TZ = UTC
  • تعيين ساعة النظام الخاص بك إلى UTC
  • عدم استخدام التطبيقات المترجمة مطلقًا ما لم يكن ضروريًا تمامًا (أي للعرض فقط)

لأعضاء عملية مجتمع جافا أوصي:

  • جعل الطرق المترجمة ليست الافتراضية ، ولكن تتطلب من المستخدم طلب الترجمة بشكل صريح.
  • استخدم UTF-8 / UTC مثل الافتراضي FIXED بدلا من ذلك لأنه ببساطة الافتراضي اليوم. لا يوجد سبب للقيام بشيء آخر ، إلا إذا كنت ترغب في إنتاج سلاسل محادثات كهذه.

أعني ، هيا ، أليست متغيرات ثابتة عالمية نمطًا مضادًا لـ OO؟ لا شيء آخر هو تلك الافتراضات المنتشرة من قبل بعض المتغيرات البيئة البدائية .......