কেন এই দুটি বার বিয়োগ (1927 সালে) একটি আজব ফলাফল দিচ্ছে?

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?

যদি আমি পরে তারিখগুলি 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

Comments

এটি স্থানীয় সমস্যা হতে পারে।

— থরবজর্ন রাভন অ্যান্ডারসন

আসল উত্তর হ'ল সর্বদা, ইউনিক্সের মতো log৪ বিট পূর্ণসংখ্যার উপস্থাপনা (যেমন আপনি যদি পর্বের আগে স্ট্যাম্পের অনুমতি দিতে চান তবে) স্বাক্ষরিত, লগিংয়ের জন্য একটি যুগের পর থেকে সর্বদা সেকেন্ড ব্যবহার করুন। যে কোনও রিয়েল-ওয়ার্ল্ড টাইম সিস্টেমে লিপ আওয়ার বা দিবালোকের সঞ্চয় হিসাবে কিছু অ-রৈখিক, একঘেয়েমিবিহীন আচরণ থাকে।

— ফিল এইচ

হাঃ হাঃ হাঃ. তারা এটি ২০১১ সালে জেডিকে for এর জন্য স্থির করেছিল Then তার পরের দু'বছর পরে তারা আবিষ্কার করেছিল যে এটি জেডিকে 7-তেও ঠিক করা উচিত। 7u25 হিসাবে অবশ্যই নির্ধারিত, রিলিজ নোটটিতে আমি কোনও ইঙ্গিত পাইনি। কখনও কখনও আমি আশ্চর্য করি যে ওরাকল কয়টি বাগ সংশোধন করে এবং PR এর কারণে কাউকে এটি সম্পর্কে কিছু বলেনা।

— ব্যবহারকারী 1050755

এই ধরণের জিনিস সম্পর্কে দুর্দান্ত ভিডিও: youtube.com/watch?v=-5wpm-gesOY

— থরবজর্ন রাভন অ্যান্ডারসেন

@ ফিল্ন দ্য নিস জিনিসটি হ'ল, এখনও লিপ সেকেন্ড থাকবে। এমনকি যে কাজ করে না।

— 12431234123412341234123

Answer 1

এটি সাংহাইতে 31 ডিসেম্বর একটি সময় অঞ্চল পরিবর্তন।

সাংহাইতে 1927 এর বিশদের জন্য এই পৃষ্ঠাটি দেখুন । মূলত 1927 এর শেষে মধ্যরাতে, ঘড়িগুলি 5 মিনিট 52 52 সেকেন্ড পিছনে চলে যায়। সুতরাং "1927-12-31 23:54:08" আসলে দুবার ঘটেছে এবং দেখে মনে হচ্ছে জাভা সেই স্থানীয় তারিখ / সময়ের জন্য পরবর্তী সম্ভাব্য তাত্ক্ষণিক হিসাবে পার্স করছে - সুতরাং পার্থক্য।

সময় অঞ্চলগুলির প্রায়শই অদ্ভুত এবং দুর্দান্ত বিশ্বের কেবল একটি পর্ব।

সম্পাদনা: প্রেস বন্ধ করুন! ইতিহাস পরিবর্তন ...

টিজেডডিবি-র 2013a সংস্করণ দিয়ে পুনর্নির্মাণ করা হলে মূল প্রশ্নটি আর একই রকম আচরণ করে না । 2013a এ, ফলাফলটি হবে 358 সেকেন্ডের, 23:54:08 এর পরিবর্তে 23:54:03 এর রূপান্তর সময়ের সাথে।

আমি কেবল এটি লক্ষ্য করেছি কারণ আমি ইউনিট পরীক্ষার আকারে নোদা সময়ে এই জাতীয় প্রশ্ন সংগ্রহ করছি ... পরীক্ষাটি এখন পরিবর্তন করা হয়েছে, তবে এটি কেবল প্রদর্শন করতে চলেছে - এমনকি historicalতিহাসিক তথ্যও নিরাপদ নয়।

সম্পাদনা: ইতিহাস আবার পরিবর্তন হয়েছে ...

টিজেডডিবি ২০১৪ সালে, পরিবর্তনের সময়টি ১৯০০-১২-৩১ এ চলে গেছে, এবং এখন এটি সবেমাত্র ৩৪৩ সেকেন্ডের পরিবর্তন (সুতরাং সময়টির মধ্যবর্তী সময়টি tএবং t+1344 সেকেন্ডের, যদি আপনি কী বোঝাতে চান তবে)।

সম্পাদনা: 1900-এ পরিবর্তনের আশেপাশের একটি প্রশ্নের উত্তর দেওয়ার জন্য ... দেখে মনে হচ্ছে জাভা টাইমজোন বাস্তবায়ন সমস্ত সময় অঞ্চলগুলি কেবল 1900 ইউটিসি শুরুর আগে কোনও তাত্ক্ষণিক জন্য তাদের মানসম্পন্ন সময় হিসাবে বিবেচনা করে :

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

উপরের কোডটি আমার উইন্ডোজ মেশিনে কোনও আউটপুট তৈরি করে না। সুতরাং যে কোনও সময় অঞ্চল 1900 এর শুরুতে এর মানক ব্যতীত অন্য কোনও অফসেট রয়েছে তা এটিকে রূপান্তর হিসাবে গণ্য করবে। TZDB নিজেই এর আগে কিছুটা তথ্য ফিরে পেয়েছিল এবং কোনও "নির্দিষ্ট" মানক সময় (যা এটি getRawOffsetএকটি বৈধ ধারণা হিসাবে ধরে নেওয়া হয়) এর কোনও ধারণার উপর নির্ভর করে না তাই অন্যান্য গ্রন্থাগারগুলিতে এই কৃত্রিম স্থানান্তরটি প্রবর্তন করার প্রয়োজন নেই।

Comments

@ জোন: কৌতূহলবশত, তারা কেন তাদের ঘড়িগুলি এমন "অদ্ভুত" ব্যবধানে পিছনে ফেলেছিল? এক ঘন্টার মতো যে কোনও কিছু যৌক্তিক মনে হলেও এটি 5: 52 মিনিট কীভাবে আসবে?

— জোহানেস রুডলফ

@ জোহানেস: এটিকে আরও বিশ্বব্যাপী স্বাভাবিক সময় অঞ্চল হিসাবে গড়ে তোলার জন্য, আমি বিশ্বাস করি - ফলাফলটি অফসেটটি ইউটিসি +8। 1911 সালে প্যারিস একই ধরণের কাজ করেছিল উদাহরণস্বরূপ: সময় ও তারিখ / ওয়ার্ল্ডক্লক / ক্লকচেন্চ html?n=195&year=

— জন স্কিটি

@ জন আপনি কি জানবেন যে জাভা / .NET সেপ্টেম্বরের সাথে 1752 তে কপি করে? আমি সর্বদা লোকদের ইউনিক্স সিস্টেমে 9 1752 ক্যাল দেখাতে পছন্দ করতাম

— মিঃ মোঃ

তাহলে কেন হ্যাকটি প্রথম স্থানে শ্যাঙ্গাইয়ের 5 মিনিটের বাইরে ছিল?

— ইগবি লার্জম্যান

@ চার্লস: প্রচুর জায়গাগুলিতে তখন প্রচলিত অফসেট কম ছিল had কিছু দেশে, বিভিন্ন শহরে প্রত্যেকের নিজস্ব অফসেট যতটা সম্ভব ভৌগোলিকভাবে সঠিকভাবে কাছাকাছি থাকতে হয়েছিল।

— জন স্কিটি

Answer 2

আপনি একটি স্থানীয় সময় বিচ্ছিন্নতার মুখোমুখি হয়েছেন :

স্থানীয় মানক সময়টি যখন রবিবার পৌঁছতে চলেছিল, ১ জানুয়ারী ১৯৮২, 00:00:00 ঘড়িগুলি শনিবার, 31 ডিসেম্বর 1927, 23:54:08 পরিবর্তে স্থানীয় সময় অনুযায়ী 0.05:52 ঘন্টা পিছনে ফিরে গেছে

এটি বিশেষত বিস্ময়কর নয় এবং রাজনৈতিক বা প্রশাসনিক ক্রিয়াকলাপের কারণে টাইমজোনগুলি পরিবর্তন বা পরিবর্তিত হওয়ার কারণে এক সময় বা অন্য সময়ে সর্বত্র ঘটেছিল much

Answer 3

এই অদ্ভুততার নৈতিকতা হ'ল:

• ইউটিসিতে যেখানেই সম্ভব তারিখ এবং সময় ব্যবহার করুন।
• আপনি যদি ইউটিসিতে কোনও তারিখ বা সময় প্রদর্শন করতে না পারেন তবে সর্বদা সময় অঞ্চলটি নির্দেশ করুন।
• আপনি যদি ইউটিসিতে ইনপুট তারিখ / সময় প্রয়োজন না পারেন তবে একটি স্পষ্টভাবে নির্দেশিত সময়-অঞ্চল প্রয়োজন।

Comments

ইউটিসিতে রূপান্তর / সঞ্চয় স্থানটি বর্ণিত সমস্যার জন্য সত্যই সহায়তা করবে না কারণ আপনি ইউটিসিতে রূপান্তরকালে বিচ্ছিন্নতার মুখোমুখি হবেন।

— অযৌক্তিক

@ মারক মান: আপনার প্রোগ্রামটি যদি কেবলমাত্র ইউআইতে স্থানীয় সময় অঞ্চল থেকে / থেকে রূপান্তর করে অভ্যন্তরীণভাবে সর্বত্র ইউটিসি ব্যবহার করে, আপনি এই ধরনের বিচ্ছিন্নতাগুলির যত্ন নেবেন না ।

— রায়েডওয়াল্ড

@ রেয়েডওয়াল্ড: নিশ্চয়ই আপনি যাবেন - 1927-12-31 23:54:08 এর ইউটিসি সময়টি কী? (এই মুহূর্তের জন্য উপেক্ষা করা, ইউটিসি 1927 সালেও উপস্থিত ছিল না)। এ কিছু বিন্দু এই সময় এবং তারিখ আপনার সিস্টেমে উদ্ভেদ হয়, এবং আপনি এটি দিয়ে কি করতে সিদ্ধান্ত নিতে। ব্যবহারকারীকে ইউটিসিতে সময় ইনপুট করতে হবে তা বলার ফলে সমস্যাটি কেবল ব্যবহারকারীকে সরিয়ে দেয়, এটি এটিকে সরিয়ে দেয় না।

— নিক বেস্টিন

আমি প্রায় এক বছর ধরে একটি বৃহত অ্যাপ্লিকেশনটির তারিখ / সময় রিফ্যাক্টরিংয়ে কাজ করে এই থ্রেডটিতে ক্রিয়াকলাপের পরিমাণকে প্রমাণ করছি। আপনি যদি ক্যালেন্ডারিংয়ের মতো কিছু করেন তবে আপনি "সহজভাবে" ইউটিসি সংরক্ষণ করতে পারবেন না, কারণ সময় অঞ্চলগুলির যে সংজ্ঞা দেওয়া হয়েছে এটি সময়ের সাথে সাথে পরিবর্তিত হবে will আমরা "ব্যবহারকারীর উদ্দেশ্য সময়" - ব্যবহারকারীর স্থানীয় সময় এবং তাদের সময় অঞ্চল - এবং অনুসন্ধান এবং বাছাইয়ের জন্য ইউটিসি এবং যখনই আইএএনএ ডাটাবেস আপডেট করা হয়, আমরা সমস্ত ইউটিসি সময় পুনরায় গণনা করি।

— তাইগানৌত

Answer 4

সময় বাড়ানোর সময় আপনার আবার ইউটিসিতে রূপান্তর করা উচিত এবং তারপরে যুক্ত বা বিয়োগ করা উচিত। স্থানীয় সময়টি কেবল প্রদর্শনের জন্য ব্যবহার করুন।

এইভাবে আপনি যে কোনও সময় পেরিয়ে হাঁটাতে সক্ষম হবেন যেখানে ঘন্টা বা মিনিট দু'বার ঘটে।

আপনি যদি ইউটিসিতে রূপান্তর করেন তবে প্রতিটি সেকেন্ড যুক্ত করুন এবং স্থানীয় সময় প্রদর্শনের জন্য রূপান্তর করুন। আপনি 11:54:08 pm LMT - 11:59:59 pm LMT এবং তারপরে 11:54:08 pm CST - 11:59:59 pm CST এ যাবেন ।

Answer 5

প্রতিটি তারিখ রূপান্তর করার পরিবর্তে, আপনি নিম্নলিখিত কোডটি ব্যবহার করতে পারেন:

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

এবং তারপরে দেখুন ফলাফলটি:

1

Comments

আমি ভীত যে ঘটনাটি না। আপনি আমার সিস্টেমে আমার কোডটি চেষ্টা করে দেখতে পারেন, এটি আউটপুট দেবে 1, কারণ আমাদের আলাদা লোকাল রয়েছে।

— ফ্রিউইন্ড

এটি কেবল সত্য কারণ আপনি পার্সার ইনপুটটিতে লোকেল নির্দিষ্ট করেন নি। এটি খারাপ কোডিং শৈলী এবং জাভাতে একটি বিশাল ডিজাইনের ত্রুটি - এর অন্তর্নিহিত স্থানীয়করণ। ব্যক্তিগতভাবে, আমি এড়াতে জাভা ব্যবহার করি না কেন আমি যেখানেই "TZ = UTC LC_ALL = C" রেখেছি put আপনি যদি কোনও ব্যবহারকারীর সাথে সরাসরি ইন্টারঅ্যাক্ট না করে এবং স্পষ্টভাবে না চান তবে আপনার প্রয়োগের প্রতিটি স্থানীয় সংস্করণ এড়ানো উচিত। স্থানীয়করণ সহ যে কোনও গণনা করবেন না, সর্বদা লোকাল.আরআউট এবং ইউটিসি টাইমজোনগুলি একেবারে প্রয়োজনীয় না হলে ব্যবহার করুন।

— ব্যবহারকারী 1050755

Answer 6

আমি দুঃখের সাথে বলতে চাই, তবে সময় বিচ্ছিন্নতা কিছুটা এগিয়ে গেছে

দু'বছর আগে জেডিকে 6 , এবং জেডিকে 7 তে সম্প্রতি 25 আপডেট হয়েছে ।

শেখার পাঠ: প্রদর্শন ব্যতীত ইউটিসি-র সময় সর্বদা ব্যয় করুন avoid

Comments

এটি ভুল। বিচ্ছিন্নতা কোনও ত্রুটি নয় - এটি কেবলমাত্র TZDB- র একটি সাম্প্রতিক সংস্করণে কিছুটা আলাদা ডেটা রয়েছে। উদাহরণস্বরূপ, জাভা 8 সহ আমার মেশিনে, আপনি যদি "1927-12-31 23:54:02" এবং "1927-12-31 23:54:03" ব্যবহার করতে কোডটি খুব সামান্য পরিবর্তন করেন তবে আপনি এখনও একটি দেখতে পাবেন বিরতি - তবে 353 এর পরিবর্তে এখন 358 সেকেন্ডের T TZDB এর আরও সাম্প্রতিক সংস্করণগুলিতে আরও একটি পার্থক্য রয়েছে - বিশদগুলির জন্য আমার উত্তর দেখুন। এখানে সত্যিকারের বাগ নেই, দ্বিপাক্ষিক তারিখ / সময়ের পাঠ্য মানগুলি কীভাবে পার্স করা হয় তার চারদিকে কেবল একটি নকশার সিদ্ধান্ত।

— জন স্কিটি

আসল সমস্যাটি হ'ল প্রোগ্রামাররা বুঝতে পারে না যে স্থানীয় এবং সার্বজনীন সময়ের (যে কোনও দিকের) মধ্যে রূপান্তর হয় না এবং এটি 100% নির্ভরযোগ্য হতে পারে না। পুরানো টাইমস্ট্যাম্পগুলির জন্য আমাদের কাছে স্থানীয় সময়টি কী ছিল তা সর্বোপরি নড়বড়ে data ভবিষ্যতের টাইমস্ট্যাম্পগুলির জন্য রাজনৈতিক ক্রিয়াগুলি সর্বজনীন সময়কে প্রদত্ত স্থানীয় সময়ের মানচিত্রে পরিবর্তন করতে পারে। বর্তমান এবং সাম্প্রতিক অতীত টাইমস্ট্যাম্পগুলির জন্য আপনার সমস্যা হতে পারে যে আইন প্রয়োগের সময়সূচীর চেয়ে tz ডাটাবেস আপডেট করার এবং পরিবর্তনগুলি আনা প্রক্রিয়াটি ধীর হতে পারে।

— প্লাগওয়াশ

Answer 7

অন্যদের দ্বারা ব্যাখ্যা করা হিসাবে, সেখানে একটি সময় বিরতি। সেখানে জন্য দুটি সম্ভাব্য সময় অঞ্চল অফসেট হয় 1927-12-31 23:54:08এ Asia/Shanghai, কিন্তু শুধুমাত্র এক জন্য অফসেট 1927-12-31 23:54:07। সুতরাং, অফসেটটি কোনটি ব্যবহৃত হয় তার উপর নির্ভর করে একটি হয় দ্বিতীয় সেকেন্ড পার্থক্য বা 5 মিনিট এবং 53 সেকেন্ডের পার্থক্য।

অফসেটের এই সামান্য শিফটটি, আমাদের এক ঘন্টার স্বাভাবিক দিবালোক সঞ্চয় (গ্রীষ্মকালীন সময়) এর পরিবর্তে সমস্যাটি কিছুটা অস্পষ্ট করে।

নোট করুন যে টাইমজোন ডাটাবেসের 2013a আপডেটটি এই সীমাবদ্ধতাটি কয়েক সেকেন্ড আগে সরিয়ে নিয়েছিল, তবে এর প্রভাবটি এখনও পর্যবেক্ষণযোগ্য হবে।

java.timeজাভা 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 সেকেন্ড হবে।

এছাড়াও, এই দুটি অফসেট একই:

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

আপনি সেই তারিখ / সময়টির জন্য একাধিক বৈধ অফসেট বা সেই ফাঁক যেখানে date অঞ্চল আইডির জন্য সেই তারিখ / সময়টি বৈধ নয় - সেখানে isOverlap()এবং isGap()পদ্ধতিগুলি ব্যবহার করে ট্রানজিশনটি ওভারল্যাপ কিনা তা আপনি পরীক্ষা করতে পারেন zot4।

আমি আশা করি একবার জাভা 8 ব্যাপকভাবে উপলব্ধ হয়ে উঠলে বা JSR 310 ব্যাকপোর্ট গ্রহণকারী জাভা 7 ব্যবহারকারীদের কাছে এটি এই ধরণের সমস্যাটিকে পরিচালনা করতে সহায়তা করে।

Comments

হাই ড্যানিয়েল, আমি আপনার কোডের টুকরোটি চালিয়েছি তবে এটি আশানুরূপ আউটপুট দিচ্ছে না। সময়কাল যেমন আটটিয়ারিয়াল অফসেট এবং সময়কালআউটলেটার অফসেট উভয়ই কেবল 1 সেকেন্ড এবং zot3 এবং zot4 উভয়ই নাল। আমি আমার কম্পিউটারে এই কোডটি অনুলিপি করে চালিয়েছি। এখানে কিছু করার দরকার আছে কি? আপনি যদি কোডের একটি অংশ দেখতে চান তবে আমাকে জানান। এখানে কোড টিউটোরিয়ালস্পয়েন্ট করুন .com/ আপনি এখানে কী চলছে তা আমাকে জানাতে পারেন।

— ভিনেশচাউহন

@ ভিনিশচাউহান এটি জাভার সংস্করণের উপর নির্ভর করে, কারণ এটি তজদাটাতে পরিবর্তিত হয়েছে, এবং জেডিকে-র বিভিন্ন সংস্করণ tzdata এর বিভিন্ন সংস্করণকে বান্ডিল করে। আমার নিজের ইনস্টল করা জাভাতে, সময়গুলি রয়েছে 1900-12-31 23:54:16এবং 1900-12-31 23:54:17এটি আপনার ভাগ করা সাইটে কাজ করে না, তাই তারা আই এর চেয়ে আলাদা জাভা সংস্করণ ব্যবহার করছে

— ড্যানিয়েল সি সোব্রাল

Answer 8

আইএমএইচও জাভার বিস্তৃত, অন্তর্নিহিত স্থানীয়করণ এটির একক বৃহত্তম ডিজাইনের ত্রুটি। এটি ব্যবহারকারীর ইন্টারফেসের জন্য লক্ষ্যযুক্ত হতে পারে তবে প্রকৃতপক্ষে, কিছু আইডিই যেখানে আপনি মূলত স্থানীয়করণকে উপেক্ষা করতে পারেন তবে যিনি ব্যবহারকারীর ইন্টারফেসের জন্য সত্যই জাভা ব্যবহার করেন তিনি কারণ প্রোগ্রামাররা এটির জন্য লক্ষ্যমাত্র শ্রোতা নয়। আপনি এটিকে ঠিক করতে পারেন (বিশেষত লিনাক্স সার্ভারগুলিতে):

• LC_ALL = C TZ = UTC রফতানি করুন
• আপনার সিস্টেমের ঘড়িটি ইউটিসি তে সেট করুন
• একেবারে প্রয়োজনীয় না হলে কখনও কখনও স্থানীয়করণের প্রয়োগগুলি ব্যবহার করবেন না (যেমন শুধুমাত্র প্রদর্শনের জন্য)

করার জাভা কমিউনিটি প্রসেস সদস্যদের আমি সুপারিশ:

• স্থানীয়করণ পদ্ধতিগুলি ডিফল্ট নয়, তবে ব্যবহারকারীকে স্পষ্টতই স্থানীয়করণের জন্য অনুরোধ করতে হবে।
• পরিবর্তে ইউটিএফ -8 / ইউটিসিটিকে ফিক্সড ডিফল্ট হিসাবে ব্যবহার করুন কারণ এটি আজ কেবল ডিফল্ট। আপনি যদি এই জাতীয় থ্রেড তৈরি করতে চান তবে বাদে অন্য কিছু করার কোনও কারণ নেই।

মানে, আসুন, গ্লোবাল স্ট্যাটিক ভেরিয়েবলগুলি কি অ্যান্টি-ওও প্যাটার্ন নয়? আর কিছু নয়, কিছু প্রাথমিক পরিবেশ পরিবর্তনশীল দ্বারা প্রদত্ত সেই বিস্তৃত ডিফল্ট নয় .......

Answer 9

অন্যরা যেমন বলেছিল, এটি 1927-এর সাংহাইয়ের সময় পরিবর্তনের।

এটি যখন 23:54:07স্থানীয় মানক সময় সাংহাইতে ছিল , তবে 5 মিনিট এবং 52 সেকেন্ড পরে, এটি পরের দিনটিতে পরিণত হয়েছিল 00:00:00এবং তারপরে স্থানীয় মানের সময়টি আবার পরিবর্তিত হয়েছিল 23:54:08। সুতরাং, এই কারণেই দুটি সময়ের মধ্যে পার্থক্যটি 1 সেকেন্ড নয় 343 সেকেন্ড, যেমনটি আপনি আশা করেছিলেন।

সময়টি আমেরিকার মতো অন্যান্য জায়গায়ও গণ্ডগোল করতে পারে। আমেরিকার ডাইটলাইট সেভিং টাইম রয়েছে। যখন ডাইটলাইট সেভিং টাইম শুরু হয় তখন সময়টি 1 ঘন্টা এগিয়ে যায়। তবে কিছুক্ষণ পরে দিবালোক সংরক্ষণের সময় শেষ হয় এবং এটি 1 ঘন্টা পিছনে আদর্শ সময় অঞ্চলে চলে যায়। সুতরাং কখনও কখনও মার্কিন যুক্তরাষ্ট্রে সময় তুলনা করার সময় পার্থক্য প্রায় 36001 সেকেন্ড নয় সেকেন্ড।

তবে এই দুটি সময়ের পরিবর্তন সম্পর্কে আলাদা কিছু রয়েছে। উত্তরোত্তর ধারাবাহিকভাবে পরিবর্তন হয় এবং পূর্বেরটি কেবল একটি পরিবর্তন ছিল। এটি একই পরিমাণে ফিরে আসে না বা আবার পরিবর্তন হয় নি।

ইউটিসি ব্যবহার করা আরও ভাল যেখানে যেখানে সময় পরিবর্তিত হয় না যদি না ডিসপ্লে-এর মতো নন-ইউটিসি সময় ব্যবহারের প্রয়োজন হয়।