দিবালোক সংরক্ষণ সময় এবং সময় অঞ্চল সেরা অনুশীলন [বন্ধ]

2046

আমি এই প্রশ্নটি এবং এর উত্তরগুলি দিবালোকের সময় সাশ্রয় করার সময়, বিশেষত সত্যিকারের পরিবর্তন ওভারগুলি নিয়ে কাজ করার জন্য নির্দিষ্ট নির্দেশিকা তৈরি করার আশাবাদী।

আপনার যদি যোগ করার মতো কিছু থাকে তবে দয়া করে করুন

অনেকগুলি সিস্টেম সঠিক সময় রাখার উপর নির্ভরশীল, সমস্যাটি দিনের আলোতে সঞ্চয়ের কারণে সময়ের সাথে পরিবর্তনের সাথে থাকে - ঘড়িকে সামনে বা পিছনের দিকে চালিত করে।

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

  • দিবালোক সংরক্ষণের সমস্যাটিকে আপনি কীভাবে মোকাবেলা করেছেন?
  • অনুমানগুলি আপনার সমাধানের অংশ কি? (এখানে প্রসঙ্গ খুঁজছেন)

গুরুত্বপূর্ণ হিসাবে, যদি না আরও হয়:

  • আপনি কী চেষ্টা করেছিলেন যা কাজ করে নি?
  • কেন কাজ হয়নি?

আমি প্রোগ্রামিং, ওএস, ডেটা অধ্যবসায় এবং ইস্যুটির অন্যান্য প্রাসঙ্গিক দিকগুলিতে আগ্রহী।

সাধারণ উত্তরগুলি দুর্দান্ত, তবে আমি বিশদগুলি দেখতে চাই বিশেষত যদি সেগুলি কেবল একটি প্ল্যাটফর্মে পাওয়া যায়।

datetime  timezone  utc  dst  datetimeoffset 
— ওডেড
সূত্র
2
@ বাতিশচেভ - GETDATE()এসকিউএল -এ এই পদ্ধতিটি ইউটিসি হবে (যেমন হবে DateTime.Now)। এবং সার্ভারটি কোনও ধরণের স্বয়ংক্রিয় ডিএসটি পরিবর্তনের দ্বারা প্রভাবিত হবে না।
— ওবেদের
4
@ ওডেড: "সার্ভারে" যুক্ত করা থাকলে আমি সম্মত হতে পারি। তবে এখনও এটি অন্য অ্যাপ্লিকেশনগুলিকে প্রভাবিত করতে পারে যা স্থানীয় সময় প্রয়োজন। এটি এবং অন্যান্য কারণে আমি মনে করি ইউটিসি সময়কে স্পষ্টভাবে অনুরোধ করা ভাল।
— আবাটিশচেভ
7
ইউটিসিকে GMT- এর পক্ষে অগ্রাধিকার দেওয়া হয়েছে, কারণ এটি আরও সুনির্দিষ্টভাবে সংজ্ঞায়িত এবং কারণ কিছু অপারেটিং সিস্টেমে GMT সংজ্ঞাগুলি মিশ্রিত হয়। লোকেরা "GMT" এবং "ইউটিসি" শব্দটিকে বিনিময়যোগ্য হিসাবে বিবেচনা করা সাধারণ তবে তারা সম্পূর্ণ হয় না। প্রায় কোনও সফ্টওয়্যার / সিস্টেমের উদ্দেশ্যে ইউটিসি ব্যবহার করুন। Stackoverflow.com/questions/2292334/…
— ক্রিস জনসন
7
@ জোস্টস্টোডোলা - জন স্কিটির ' উত্তর '।
— কেনি ইভিট
1
@ তবে আপনি ধরে নিতে পারবেন না যে সার্ভারটি ইউটিসি-তে থাকবে, আমি প্রোডাকশন সার্ভারগুলি দেখেছি যেখানে টাইমজোনটি "ইউটিসি" ছিল তবে ডিএসটি প্রয়োগ হয়েছিল তাই অর্ধ বছরের বেশি সময় ধরে ইউটিসি +১ ছিল। @Abatishchev এর সাথে স্পষ্ট এবং ব্যবহারযোগ্য হতে সম্মত হন DateTime.UtcNowএবং GETUTCDATE()এটি অন্যান্য দেবগণকেও দেখায় যা আপনি এটি সম্পর্কে সত্যই চিন্তা করেছেন
— ono2012

উত্তর:

940

উত্তর এবং অন্যান্য ডেটার সংক্ষিপ্তসার: (দয়া করে আপনার যোগ করুন)

না:

  • আপনি যখনই সময়টিতে একটি নির্দিষ্ট মুহুর্তের কথা উল্লেখ করছেন, তখন একটি অবিচ্ছিন্ন মান অনুযায়ী সময় চালিয়ে যান যা দিবালোকের সঞ্চয় দ্বারা প্রভাবিত হয় না। (জিএমটি এবং ইউটিসি এই বিষয়ে সমতুল্য, তবে ইউটিসি শব্দটি ব্যবহার করা পছন্দ করা উচিত। লক্ষ্য করুন যে ইউটিসি জুলু বা জেড সময় হিসাবেও পরিচিত ))
  • পরিবর্তে আপনি যদি স্থানীয় সময় মান ব্যবহার করে একটি সময় অবিরাম থাকতে চান, তবে ইউটিসি থেকে এই নির্দিষ্ট সময়ের জন্য স্থানীয় সময় অফসেটটি অন্তর্ভুক্ত করুন (এই অফসেটটি সারা বছর বদলে যেতে পারে), যেমন টাইমস্ট্যাম্পটি পরবর্তীতে দ্ব্যর্থহীনভাবে ব্যাখ্যা করা যায়।
  • কিছু ক্ষেত্রে আপনার ইউটিসি সময় এবং সমমানের স্থানীয় সময় উভয়ই সঞ্চয় করতে হবে । প্রায়শই এটি দুটি পৃথক ক্ষেত্রের সাহায্যে করা হয়, তবে কিছু প্ল্যাটফর্ম datetimeoffsetএমন একটি প্রকারকে সমর্থন করে যা উভয়কে একক ক্ষেত্রে সংরক্ষণ করতে পারে।
  • সংখ্যাসূচক মান হিসাবে টাইমস্ট্যাম্পগুলি সংরক্ষণ করার সময়, ইউনিক্স সময় ব্যবহার করুন - যা পুরো সেকেন্ডের সংখ্যা 1970-01-01T00:00:00Z(লিপ সেকেন্ড বাদে)। আপনার যদি উচ্চতর নির্ভুলতার প্রয়োজন হয় তবে পরিবর্তে মিলিসেকেন্ড ব্যবহার করুন। এই মানটি সর্বদা কোনও সময় অঞ্চল সমন্বয় ছাড়াই ইউটিসির উপর ভিত্তি করে হওয়া উচিত।
  • আপনার যদি পরে টাইমস্ট্যাম্পটি সংশোধন করার প্রয়োজন হতে পারে তবে মূল টাইম জোন আইডি অন্তর্ভুক্ত করুন যাতে আপনি নির্ধারণ করতে পারেন যে অফসেটটি রেকর্ডকৃত মূল মান থেকে পরিবর্তিত হয়েছে কিনা।
  • ভবিষ্যতের ইভেন্টগুলির সময় নির্ধারণ করার সময়, ইউটিসির পরিবর্তে স্থানীয় সময়কেই বেশি পছন্দ করা হয়, কারণ অফসেটটি পরিবর্তন করা সাধারণ। উত্তর এবং ব্লগ পোস্ট দেখুন ।
  • পুরো তারিখগুলি, যেমন জন্মদিন এবং বার্ষিকীগুলি সংরক্ষণ করার সময়, ইউটিসি বা অন্য কোনও সময় অঞ্চলে রূপান্তর করবেন না।
    • সম্ভব হলে, কেবলমাত্র তারিখের মতো ডেটা সংরক্ষণ করুন যা দিনের কোনও সময় অন্তর্ভুক্ত করে না।
    • যদি এই ধরণের কোনও উপলভ্য না থাকে তবে মানটির ব্যাখ্যা দেওয়ার সময় সর্বদা সময়কাল উপেক্ষা করে নিশ্চিত হন। যদি আপনাকে এই আশ্বাস দেওয়া যায় না যে দিনের সময়কাল উপেক্ষা করা হবে, তবে সেই দিন আরও নিরাপদ প্রতিনিধি সময় হিসাবে রাত্রে 00:00 টার চেয়ে মধ্যরাত রাত 12:00 বাছাই করুন।
  • মনে রাখবেন যে সময় অঞ্চল অফসেটগুলি সর্বদা ঘন্টা সংখ্যার পূর্ণসংখ্যক হয় না (উদাহরণস্বরূপ, ভারতীয় স্ট্যান্ডার্ড সময়টি ইউটিসি + 05: 30, এবং নেপাল ইউটিসি + 05: 45 ব্যবহার করে)।
  • জাভা ব্যবহার করা থাকলে জাভা 8 এবং তার পরে জাভা.টাইম ব্যবহার করুন।
  • ব্যবহার যদি .NET , ব্যবহারের বিষয়ে বিবেচনা নোদা সময় ।
  • যদি নোডা সময় ব্যতীত। নেট ব্যবহার করেন, তবে DateTimeOffsetএটি প্রায়শই তার চেয়ে ভাল পছন্দ DateTime।
  • পার্ল ব্যবহার করে থাকলে ডেটটাইম ব্যবহার করুন ।
  • পাইথন ব্যবহার করা হলে পাইটজ বা ডেটুটিল ব্যবহার করুন ।
  • যদি জাভাস্ক্রিপ্ট ব্যবহার করা হয় তবে মুহুর্তের সময় অঞ্চল বিস্তারের সাথে moment.js ব্যবহার করুন ।
  • যদি পিএইচপি> 5.2 ব্যবহার করে থাকেন তবে প্রদত্ত নেটিভ টাইম অঞ্চল রূপান্তর DateTimeএবং DateTimeZoneক্লাস ব্যবহার করুন। ব্যবহার করার সময় সতর্ক থাকুন DateTimeZone::listAbbreviations()- উত্তর দেখুন । তারিখ ওলসন ডেটাতে দিয়ে পিএইচপি রাখতে, কিছু সময় অন্তর ইনস্টল timezonedb PECL প্যাকেজ; উত্তর দেখুন ।
  • সি ++ ব্যবহার করে, IANA টাইমজোন ডাটাবেস সঠিকভাবে প্রয়োগ করে এমন একটি লাইব্রেরি ব্যবহার করবেন তা নিশ্চিত হন । এর মধ্যে রয়েছে সিসিটিজ , আইসিইউ , এবং হাওয়ার্ড হিন্যান্টের "tz" লাইব্রেরি ।
    • টাইম জোনের রূপান্তরগুলির জন্য বুস্ট ব্যবহার করবেন না । যদিও এর এপিআই স্ট্যান্ডার্ড আইএএনএ (ওরফে "জোনিনফো") সনাক্তকারীকে সমর্থন করার দাবি করে, প্রতিটি জোনের যে পরিবর্তনগুলি হতে পারে তার সমৃদ্ধ ইতিহাস বিবেচনা না করে এটি অযৌক্তিকভাবে তাদের পসিক্স -স্টাইলের ডেটাতে মানচিত্র করে । (এছাড়াও ফাইলটি রক্ষণাবেক্ষণের বাইরে চলে গেছে))
  • মরিচা ব্যবহার করলে ক্রোনো ব্যবহার করুন ।
  • বেশিরভাগ ব্যবসায়িক বিধিগুলি ইউটিসি বা জিএমটি না হয়ে নাগরিক সময় ব্যবহার করে। অতএব, অ্যাপ্লিকেশন যুক্তি প্রয়োগ করার আগে ইউটিসি টাইমস্ট্যাম্পগুলি স্থানীয় সময় অঞ্চলে রূপান্তর করার পরিকল্পনা করুন।
  • মনে রাখবেন যে সময় অঞ্চল এবং অফসেটগুলি স্থির নয় এবং এটি পরিবর্তিত হতে পারে। উদাহরণস্বরূপ, historতিহাসিকভাবে মার্কিন যুক্তরাষ্ট্র এবং যুক্তরাজ্য 'স্প্রিং ফরোয়ার্ড' এবং 'পিছিয়ে পড়ে' একই তারিখ ব্যবহার করেছিল। যাইহোক, 2007 সালে মার্কিন যুক্তরাষ্ট্রের ঘড়িগুলির পরিবর্তনের তারিখগুলি পরিবর্তন করে। এর অর্থ এখন বছরের 48 সপ্তাহের জন্য লন্ডনের সময় এবং নিউইয়র্ক সময়ের মধ্যে পার্থক্য 5 ঘন্টা এবং 4 সপ্তাহের জন্য (বসন্তে 3, শরত্কালে 1) এটি 4 ঘন্টা হয়। একাধিক অঞ্চল জড়িত যে কোনও গণনায় এই জাতীয় আইটেম সম্পর্কে সচেতন হন।
  • সঠিক পুনরুদ্ধারের জন্য আপনাকে কী উপাদানগুলি (টাইমস্ট্যাম্প, টাইম জোন অফসেট এবং টাইম জোনের নাম) সংরক্ষণ করতে হবে তা সময়ের ধরণ (প্রকৃত ইভেন্টের সময়, সম্প্রচারের সময়, আপেক্ষিক সময়, timeতিহাসিক সময়, পুনরাবৃত্ত সময়) বিবেচনা করুন - এতে "সময়ের ধরণগুলি" দেখুন এই উত্তর ।
  • নিজের ও বাকি বিশ্বের মধ্যে আপনার ওএস, ডাটাবেস এবং অ্যাপ্লিকেশন tzdata ফাইলগুলি সিঙ্কে রাখুন।
  • সার্ভারগুলিতে, স্থানীয় সময় অঞ্চলের পরিবর্তে ইউটিসিতে হার্ডওয়্যার ক্লক এবং ওএস ক্লক সেট করুন।
  • পূর্ববর্তী বুলেট পয়েন্টটি নির্বিশেষে , ওয়েব সাইটগুলি সহ সার্ভার-সাইড কোডটি কখনই সার্ভারের স্থানীয় সময় অঞ্চলটি বিশেষত কিছু হওয়ার আশা করে না। উত্তর দেখুন ।
  • আপনার অ্যাপ্লিকেশন কোডে কেস-বাই-কেস ভিত্তিতে টাইম জোনের সাথে কাজ করতে পছন্দ করুন কনফিগারেশন ফাইল সেটিংস বা ডিফল্টের মাধ্যমে বিশ্বব্যাপী।
  • সমস্ত সার্ভারে এনটিপি পরিষেবা ব্যবহার করুন ।
  • যদি FAT32 ব্যবহার করে থাকেন তবে মনে রাখবেন যে টাইমস্ট্যাম্পগুলি স্থানীয় সময়ে সংরক্ষণ করা হয়, ইউটিসি নয়।
  • পুনরাবৃত্ত ইভেন্টগুলির সাথে ডিল করার সময় (সাপ্তাহিক টিভি শো, উদাহরণস্বরূপ) মনে রাখবেন যে সময়টি ডিএসটি-র সাথে পরিবর্তিত হয় এবং সময় অঞ্চলগুলিতে আলাদা হবে।
  • সর্বদা তারিখ-সময় মানগুলি নিম্ন-সীমাবদ্ধ অন্তর্ভুক্ত, উচ্চ-বাউন্ড এক্সক্লুসিভ ( >=, <) হিসাবে জিজ্ঞাসা করুন ।

না:

  • কোনও "টাইম অঞ্চল" বিভ্রান্ত করবেন না, যেমন America/New_York"টাইম জোন অফসেট" দিয়ে যেমন -05:00। তারা দুটি ভিন্ন জিনিস. দেখুন টাইমজোন ট্যাগ উইকি ।
  • Dateপুরানো ওয়েব ব্রাউজারগুলিতে তারিখ এবং সময় গণনা সম্পাদনের জন্য জাভাস্ক্রিপ্টের অবজেক্টটি ব্যবহার করবেন না , কারণ ECMAScript 5.1 এবং নিম্নের একটি ডিজাইনের ত্রুটি রয়েছে যা দিবালোক সংরক্ষণের সময়টিকে ভুলভাবে ব্যবহার করতে পারে। (এটি ECMAScript 6/2015 এ স্থির করা হয়েছিল)।
  • ক্লায়েন্টের ঘড়িতে কখনও বিশ্বাস করবেন না। এটি খুব ভাল ভুল হতে পারে।
  • লোকদের "সর্বদা সর্বত্র ইউটিসি ব্যবহার করতে" বলুন না। এই বিস্তৃত পরামর্শটি এই নথিতে আগে বর্ণিত বেশ কয়েকটি বৈধ দৃশ্যের সংক্ষিপ্তসার রয়েছে। পরিবর্তে, আপনি যে ডেটা নিয়ে কাজ করছেন তার উপযুক্ত সময়সূত্রটি ব্যবহার করুন। ( টাইমস্ট্যাম্পিং ইউটিসি ব্যবহার করতে পারে তবে ভবিষ্যতের সময়সূচী এবং কেবলমাত্র তারিখের মানগুলি ব্যবহার করা উচিত নয়))

পরীক্ষামূলক:

  • পরীক্ষা করার সময়, নিশ্চিত হয়ে নিন যে আপনি পশ্চিম, পূর্ব, উত্তর এবং দক্ষিণ গোলার্ধের দেশগুলি (বাস্তবে বিশ্বের প্রতিটি কোয়ার্টারে, তাই 4 অঞ্চল), উভয়ই ডিএসটি অগ্রগতিতে এবং (নয় 8) প্রদান করে এবং এমন একটি দেশ পরীক্ষা করেছেন ডিএসটি ব্যবহার করবেন না (সমস্ত অঞ্চল কভার করার জন্য আরও 4 টি, মোট 12 টি তৈরি করে)।
  • ডিএসটি-র পরীক্ষার স্থানান্তর, যেমন আপনি বর্তমানে গ্রীষ্মের সময় থাকাকালীন শীতকাল থেকে একটি সময় মান নির্বাচন করুন।
  • টেস্ট বাউন্ডারি কেসগুলি, যেমন একটি টাইমজোনটি ইউটিসি +১২, ডিএসটি দিয়ে স্থানীয় সময়কে ইউটিসি +১ summer তৈরি করে এবং গ্রীষ্মে ইউটিসি + ১৩ এমনও করে তোলে
  • সমস্ত তৃতীয় পক্ষের লাইব্রেরি এবং অ্যাপ্লিকেশন পরীক্ষা করুন এবং নিশ্চিত করুন যে তারা সময় অঞ্চল ডেটা সঠিকভাবে পরিচালনা করেছে।
  • অন্ততপক্ষে আধ ঘন্টা সময় অঞ্চল পরীক্ষা করুন।

রেফারেন্স:

অন্য:

— ম্যাট জনসন
সূত্র
31
জিএমটি ব্যবহার করে সমস্যাটি সত্যিই সমাধান করে না, এখনও প্রয়োগ করার জন্য সঠিক ডেল্টা কী তা আপনাকে খুঁজে বের করতে হবে এবং এখানেই সমস্ত জটিলতা রয়েছে। বিভিন্ন অঞ্চলে (বিভিন্ন দিবালোক সংরক্ষণের স্যুইচ শিডিয়ুল সহ) ব্যবহারকারীরা বা historicalতিহাসিক / ভবিষ্যতের ডেটা দেখাচ্ছে এমন সিস্টেমে ব-দ্বীপটি জটিল হতে পারে।
— ckarras
10
এটি সত্য যদি সমস্ত অ্যাপ্লিকেশনটি করতে হয় তা হল স্থানীয় স্থানীয় সময়টি প্রদর্শন করা। তবে যদি আমাদের উদাহরণস্বরূপ অস্ট্রেলিয়ায় এমন একটি সার্ভার রয়েছে যার কানাডায় লেনদেনের জন্য ২ এপ্রিল ২০০ 2006 তারিখ / সময় প্রদর্শন করা দরকার (কানাডায় দিবালোক সংরক্ষণের স্যুইচিংয়ের নিয়ম পরিবর্তনের আগে এটি শেষ বছর ছিল) - আপনার কি ওএস কল আছে? যা ডেটটাইম করতে পারে ("2006/04/02 14: 35Z")। ToLocalTime () .ডায়ালাইটসাইভিং রুলস ("কানাডা", 2006) সহ?
— ckarras
22
হ্যাঁ, উইন্ডোজে এমন একটি ওএস কল রয়েছে - সিস্টেমটাইমটোটোজস্পিফিকলোকেশন। msdn.microsoft.com/en-us/library/ms724949(VS.85).aspx
— মাইকেল ম্যাডসেন
7
@ ক্রিশ্চাল সম্ভবত আপনি যদি অবিচল থাকেন তবে পারেন।
— পিটার আজতাই
16
ভবিষ্যতের তারিখগুলি (এমনকি আগামীকালও) ইউটিসিতে রূপান্তর করার বিষয়টি মনে রাখবেন আপনি সর্বদা কিছু হারাবেন। উদাহরণস্বরূপ, আপনি এই রূপান্তরটি করতে কিছু পরিচিত অফসেট ব্যবহার করেছেন, তবে যেহেতু তারিখটি ভবিষ্যতের, তাই সর্বদা একটি দল যে নিয়মগুলি সেট করে সেই নিয়মগুলিকে পরিবর্তন করবে will এছাড়াও, ভবিষ্যতের কিছু তারিখগুলি ইউটিসিতে রূপান্তর করা কার্যত অসম্ভব কারণ দিবালোক সঞ্চয়ের সময়গুলি সেই বছর অবধি জানা যায় না (কিছু দেশ প্রতি বছর তারিখ নির্ধারণ করে, 10+ বছর আগে বা কোনও সেট নিয়মের ভিত্তিতে নয়)।
— eselk
319

আমি উপরের উত্তরে আমি কী যুক্ত করতে পারি তা নিশ্চিত নই, তবে আমার কাছ থেকে কয়েকটি পয়েন্ট এখানে দেওয়া হয়েছে:

সময়ের ধরণ

চারটি ভিন্ন সময় আপনার বিবেচনা করা উচিত:

  1. ইভেন্টের সময়: উদাহরণস্বরূপ, যখন কোনও আন্তর্জাতিক ক্রীড়া ইভেন্ট ঘটে তখন বা রাজ্যাভিষেক / মৃত্যু / ইত্যাদি। এটি ইভেন্টের সময় অঞ্চলের উপর নির্ভরশীল, দর্শকের নয়।
  2. টেলিভিশনের সময়: উদাহরণস্বরূপ, একটি নির্দিষ্ট টিভি শো সারা বিশ্বের স্থানীয় সময় রাত ৯ টায় প্রচারিত হয়। আপনার ওয়েবসাইটে ফলাফল প্রকাশের বিষয়ে চিন্তা করার সময় গুরুত্বপূর্ণ (আমেরিকান আইডল বলুন)
  3. আপেক্ষিক সময়: যেমন: এই প্রশ্নের 21 ঘন্টার মধ্যে একটি খোলা অনুগ্রহ বন্ধ হবে। এটি প্রদর্শিত সহজ
  4. পুনরাবৃত্তির সময়: যেমন: ডিএসটি পরিবর্তন হওয়া সত্ত্বেও একটি টিভি শো প্রতি সোমবার রাত ৯ টায় হয় is

Histতিহাসিক / বিকল্প সময়ও আছে। এগুলি বিরক্তিকর কারণ এগুলি মানক সময়টিতে ম্যাপ নাও থাকতে পারে। উদাহরণস্বরূপ: জুলিয়ান তারিখগুলি, শনিবারের একটি ক্যালেন্ডার অনুসারে তারিখগুলি, দ্য ক্লিংগন ক্যালেন্ডার।

ইউটিসিতে স্টার্ট / স্টার্টস্ট্যাম্পগুলি ভাল কাজ করে। 1 এর জন্য আপনার ইভেন্টের পাশাপাশি একটি ইভেন্ট টাইমজোন নাম + অফসেট সংরক্ষণ করা দরকার। 2 এর জন্য, আপনার প্রতিটি অঞ্চলে সঞ্চিত স্থানীয় সময় সনাক্তকারী এবং প্রতিটি দর্শকের জন্য স্থানীয় টাইমজোন নাম + অফসেট সঞ্চিত থাকতে হবে (যদি আপনি কোনও ক্রাচ এ থাকেন তবে এটি আইপি থেকে পাওয়া সম্ভব)। 3 এর জন্য, ইউটিসি সেকেন্ডে সঞ্চয় করুন এবং সময় অঞ্চলগুলির প্রয়োজন নেই। 4 1 বা 2 কিনা এটা একটি বৈশ্বিক বা স্থানীয় ঘটনা উপর নির্ভর করে একটি বিশেষ ক্ষেত্রে দেখা যায়, কিন্তু আপনি সংরক্ষণ করার জন্য একটি প্রয়োজন সৃষ্টি টাইমস্ট্যাম্প যাতে আপনি একটি সময় অঞ্চল সংজ্ঞা আগে বা পরে এই ঘটনা তৈরি করা হয়েছে পরিবর্তিত বলতে পারেন। আপনার যদি historicতিহাসিক ডেটা দেখানোর প্রয়োজন হয় তবে এটি প্রয়োজনীয়।

সংরক্ষণের সময়

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

অফসেট এবং নাম

উপরের উদাহরণটি হ'ল:

ফুটবল বিশ্বকাপ ফাইনাল খেলাটি দক্ষিণ আফ্রিকাতে (ইউটিসি +২ - সাস্ট) ১১ ই জুলাই, ২০১০ ইউটিসি-তে অনুষ্ঠিত হয়েছিল।

এই তথ্য সঙ্গে, আমরা ঐতিহাসিকভাবে সঠিক সময় নির্ধারণ করতে পারেন যখন 2010 WCS ফাইনালে জায়গা এমনকি যদি দক্ষিণ আফ্রিকার সময় অঞ্চল সংজ্ঞা পরিবর্তন, গ্রহণ এবং যখন তারা ডাটাবেসের ক্যোয়ারী টাইমে তাদের স্থানীয় সময় অঞ্চল মধ্যে দর্শকদের কাছে দেখানো করতে সক্ষম হবেন।

সিস্টেম সময়

একে অপরের সাথে এবং বিশ্বের অন্য উভয়ের সাথে আপনার ওএস, ডাটাবেস এবং অ্যাপ্লিকেশন tzdata ফাইলগুলি সিঙ্কে রাখা এবং আপনি যখন আপগ্রেড করবেন তখন ব্যাপক পরীক্ষা করতে হবে। আপনি যে তৃতীয় পক্ষের অ্যাপ্লিকেশনটির উপর নির্ভর করেন সে টিজেড পরিবর্তনটি সঠিকভাবে পরিচালনা করে নি of

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

এছাড়াও, সমস্ত বাক্সে এনটিপিডি চালান।

ক্লায়েন্টদের মধ্যে

কোনও ক্লায়েন্ট মেশিন থেকে বৈধ হিসাবে পাওয়া টাইমস্ট্যাম্পটিকে কখনই বিশ্বাস করবেন না। উদাহরণস্বরূপ, তারিখ: HTTP শিরোনাম, বা একটি জাভাস্ক্রিপ্ট Date.getTime()কল। অস্বচ্ছ শনাক্তকারী হিসাবে ব্যবহার করার সময়, বা একই ক্লায়েন্টে একক সেশনের সময় তারিখ গণিত করার সময় এগুলি ভাল, তবে সার্ভারে থাকা আপনার মানগুলির সাথে এই মানগুলি ক্রস-রেফারেন্স করার চেষ্টা করবেন না। আপনার ক্লায়েন্টগুলি এনটিপি চালায় না, এবং তাদের বিআইওএস ঘড়ির জন্য অগত্যা একটি কার্যকারী ব্যাটারি নাও থাকতে পারে।

তুচ্ছ বস্তু

অবশেষে, সরকারগুলি কখনও কখনও খুব অদ্ভুত কাজ করবে:

নেদারল্যান্ডসে স্ট্যান্ডার্ড সময়টি ১৯৯৯-০৫-০১ থেকে ১৯3737-০6-৩০ অবধি আইন অনুসারে ইউটিসির ঠিক 19 মিনিট 32.13 সেকেন্ড এগিয়ে ছিল। এই সময় অঞ্চলটি ঠিক এইচএইচ: এমএম ফর্ম্যাট ব্যবহার করে প্রতিনিধিত্ব করা যায় না।

ঠিক আছে, আমি মনে করি আমি সম্পন্ন করেছি।

— ব্লুজমুন
সূত্র
6
এই উত্তরের কিছু দুর্দান্ত পয়েন্ট রয়েছে, আমি বিশেষত এই অংশটি "পুনরাবৃত্তির সময়:" উদাহরণটি উল্লেখ করতে চেয়েছিলাম, উদাহরণস্বরূপ: একটি টিভি শো প্রতি সোমবার রাত ৯ টায় হয়, এমনকি ডিএসটি পরিবর্তিত হয় "ডিবিতে ইউটিসিতে সময় সংরক্ষণ এবং তারপরে প্রদর্শনের জন্য রূপান্তর হ্যান্ডেলটিকে সহায়তা করে সময় অঞ্চলগুলির সাথে ডিল করার অনেক জটিল বিষয়। তবে, "পুনরাবৃত্ত ইভেন্টগুলি" পরিচালনা করা যা ডিএসটি বাধাগুলি অতিক্রম করে much
— জারেড হেলস
45
ট্রিভিয়ার জন্য +1। বিষয়বস্তু আকর্ষণীয় রাখা এই কাজটিকে আরও আনন্দদায়ক করে তোলে, যা উত্পাদনশীলতা বাড়িয়ে তুলতে পারে :)
— ক্রিস
4
এই উত্তরে অনেক ভাল জিনিস, তবে কয়েকটি বিষয়। 1) অনেক সময় অঞ্চল সংক্ষিপ্ত বিবরণ অস্পষ্ট। এখানে দেখুন 2) আপনি সবসময় ইউটিসিতে সঞ্চয় করতে চান না। বেশিরভাগ সময় - হ্যাঁ, তবে প্রসঙ্গটি গুরুত্বপূর্ণ। আপনার শর্তাবলী, টেলিভিশন সময় ইউটিসিতে সংরক্ষণ করা হবে না। এছাড়াও, কখনও কখনও এর বেআইনী বা স্থানীয় সময় সংরক্ষণ না করা নীতির বিরুদ্ধে - যা DateTimeOffset(বা সমতুল্য) মতো জিনিস কাজে আসে। অন্যথায়, ভাল লিখুন।
— ম্যাট জনসন-পিন্ট
1
সুতরাং, সকলেই সম্মত হন যে জোডা পাঠাগারটি এখন পর্যন্ত কাজের জন্য সর্বোত্তমতম সরঞ্জাম। যাইহোক, আমাদের সর্বশেষ সময়সীমার তথ্যের সাথে আপ টু ডেট রাখার জন্য আমাদের এই নিবন্ধ ( joda.org/joda-time/tz_update.html ) অনুসারে JODA জার ফাইল আপডেট (পুনর্নির্মাণ) করা দরকার । আইএএনএ ওয়েবসাইট ( iana.org/ime-zones ) থেকে সর্বশেষ টাইমজোন ডেটা ডাউনলোড করার এবং জোডা লাইব্রেরিটি পুনর্নির্মাণের কোনও স্ট্যান্ডার্ড উপায় আছে কি ? অন্য কথায়, এই প্রক্রিয়াটি ম্যানুয়ালি করার চেয়ে কি স্বয়ংক্রিয়ভাবে চালানো সম্ভব?
— সরভানা_পিসি
2
নেদারল্যান্ডসের ট্রিভিয়াকে বৈধ মনে হচ্ছে। ietf.org/rfc/rfc3339.txt বিভাগ 5.8। হাফওয়েতে দেখা গেল কেউ আমাদের পা টানছে।
— রাফিন
89

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

ধারণাগত দৃষ্টিকোণ থেকে, একজন সাধারণত দুই ধরণের সময়-তারিখের ডেটা নিয়ে কাজ করেন এবং তাদের পার্থক্য করা সুবিধাজনক (উপরের মানগুলি না করে): " শারীরিক সময় " এবং " নাগরিক সময় "।

সময়ের একটি "শারীরিক" তাত্ক্ষণিকতা অবিচ্ছিন্ন সর্বজনীন টাইমলাইনের একটি বিষয় যা পদার্থবিজ্ঞান ডিল করে (অবশ্যই আপেক্ষিকতা উপেক্ষা করে)। এই ধারণাটি ইউটিসি-তে পর্যাপ্ত পরিমাণে কোডেড-বজায় রাখা যেতে পারে, উদাহরণস্বরূপ (যদি আপনি লিপ সেকেন্ড উপেক্ষা করতে পারেন)।

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

বিষয়টি বিভ্রান্তিকর কারণ আমরা এই ধরণের ঘটনাগুলি আন্তঃবিন্যভাবে বলি এবং নাগরিক সময়গুলি রাজনৈতিক পরিবর্তনের সাপেক্ষে। সমস্যা (এবং এই ধারণাগুলি আলাদা করার প্রয়োজন) ভবিষ্যতের ইভেন্টগুলির জন্য আরও স্পষ্ট হয়ে ওঠে। উদাহরণ (আমার আলোচনা থেকে এখানে নেওয়া ।

জন তার ক্যালেন্ডারে তারিখের সময় কিছু ইভেন্টের জন্য একটি অনুস্মারক রেকর্ড করে 2019-Jul-27, 10:30:00, টিজেড = Chile/Santiago, (যা জিএমটি -4 অফসেট করেছে, সুতরাং এটি ইউটিসির সাথে সম্পর্কিত 2019-Jul-27 14:30:00)। তবে ভবিষ্যতের কোনও দিন, দেশটি টিজেড অফসেটকে জিএমটি -5 এ পরিবর্তন করার সিদ্ধান্ত নিয়েছে।

এখন, যখন দিনটি আসবে ... সেই অনুস্মারকটি চালু করা উচিত

ক) 2019-Jul-27 10:30:00 Chile/Santiago = UTC time 2019-Jul-27 15:30:00?

অথবা

খ) 2019-Jul-27 9:30:00 Chile/Santiago = UTC time 2019-Jul-27 14:30:00?

কোনও সঠিক উত্তর নেই, যদি না জন জানেন যে তিনি যখন ক্যালেন্ডারটি "দয়া করে আমাকে রিং করুন" বলছিলেন তখন ধারণামূলকভাবে কী বোঝাতে চেয়েছিলেন 2019-Jul-27, 10:30:00 TZ=Chile/Santiago।

তার অর্থ কি "নাগরিক তারিখ-সময়" ("যখন আমার শহরের ঘড়িগুলি 10:30" বলবে)? সেক্ষেত্রে ক) সঠিক উত্তর।

বা তার অর্থ কি একটি "শারীরিক তাত্ক্ষণিক তাত্ক্ষণিক", ​​যা আমাদের মহাবিশ্বের সময়ের ধারাবাহিক লাইনের একটি বিন্দু ছিল, "পরবর্তী সূর্যগ্রহণ কখন হবে" বলেছিলেন। সেক্ষেত্রে, উত্তর বি) সঠিকটি।

কয়েকটি তারিখ / সময়ের এপিআইগুলি এই পার্থক্যটি সঠিকভাবে পায়: তাদের মধ্যে জোডাটাইম , যা পরবর্তী (তৃতীয়!) জাভা ডেটটাইম এপিআই (জেএসআর 310) এর ভিত্তি।

— লিওনব্লয়
সূত্র
1
এপিআইগুলিতে আমি সম্বোধন করে দেখিনি এমন আরেকটি বিষয় হ'ল সময় এবং সময় অঞ্চল দেওয়া হলেও, "13: 00: 00EDT" এর জন্য কমপক্ষে দুটি প্রশংসনীয় অর্থ রয়েছে pla এটি এমন কিছুর উল্লেখ করা যেতে পারে যা স্থানীয় সময় দুপুর ১ টা নাগাদ ঘটেছিল, যা পূর্ব দিনের আলো সময় বলে মনে করা হত, বা এমন কিছু যা পূর্ব সময় ১৩:৩০ এর দিকে আঘাত হচ্ছিল এমন মুহুর্তে ঘটেছে বলে মনে করা হয়, যা বিশ্বাস করা হয় পূর্ব দিবালোক সময় পালন করে এমন জায়গায় ঘটেছে। কারও কাছে যদি এমন অনেক টাইমস্ট্যাম্প থাকে যেখানে টাইম-জোন সম্পর্কিত তথ্য ভুল হতে পারে (যেমন ডিজিটাল ক্যামেরা ফাইলগুলি ...)
— সুপারক্যাট
1
... তারা সঠিক স্থানীয় সময় বা বিশ্ব সময় প্রতিফলিত করে কিনা তা জেনে রাখা কীভাবে তাদের সংশোধন করবেন তা নির্ধারণে গুরুত্বপূর্ণ হতে পারে।
— সুপারক্যাট
3
স্পষ্টতই জন এ চায়) কারণ লোকেরা সাড়ে আটটায় কাজ করতে যান, বর্তমানে ডিএসটি বা টাইমজোন যাই হোক না কেন। তারা ডিএসটিতে গেলে তারা সাড়ে আটটায় কাজ করতে যাবেন, যখন তারা ডিএসটি থেকে প্রস্থান করবেন, তখন তারা সাড়ে আটটায় কাজে যাবেন। যদি দেশটি অন্য টাইমজোন স্থানান্তরের সিদ্ধান্ত নেয়, তারা 8:30 এভিডে কাজ করতে যাবেন
— Gianluca Ghettini
59

উদ্বেগের স্পষ্ট স্থাপত্য বিভাজন তৈরি করুন - কোন স্তরটি ব্যবহারকারীদের সাথে ঠিক কী ইন্টারঅ্যাক্ট করে তা জানতে এবং ক্যানোনিকাল উপস্থাপনা (ইউটিসি) এর জন্য / থেকে তারিখ-সময় পরিবর্তন করতে হবে। নন-ইউটিসি-র তারিখ-সময় উপস্থাপনা (ব্যবহারকারীদের স্থানীয় সময় অঞ্চল অনুসরণ করে), ইউটিসি সময়টি মডেল (ব্যাক-এন্ড এবং মাঝারি স্তরের জন্য অনন্য থাকে)।

এছাড়াও, আপনার প্রকৃত শ্রোতা কী, আপনার কী পরিবেশন করতে হবে না এবং কোথায় লাইন আঁকবেন তা স্থির করুন । বিদেশী ক্যালেন্ডারগুলিতে স্পর্শ করবেন না যদি না আপনার কাছে সেখানে গুরুত্বপূর্ণ গ্রাহক থাকে এবং তারপরে কেবলমাত্র সেই অঞ্চলের জন্য পৃথক ব্যবহারকারী-মুখোমুখি সার্ভার (গুলি) বিবেচনা করুন।

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

যদি সেখানে historicalতিহাসিক নিরীক্ষণের বাধ্যবাধকতা জড়িত থাকে (যেমন এজেজেডে জো 2 বছর আগে সেপ্টেম্বরে যখন বিল দিয়েছিল ঠিক তখনই জানান) তবে ইউটিসি এবং স্থানীয় সময় উভয়ই রেকর্ডের জন্য রাখুন (আপনার রূপান্তর সারণী সময়ের সাথে সাথে পরিবর্তন হবে)।

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

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

— জেডএক্সএক্স
সূত্র
40

আপনার ওলসন tz ডাটাবেস সম্পর্কে জানতে হবে যা ftp http://elsie.nci.nih.gov/pub http://iana.org/time-zones/ থেকে পাওয়া যায় । বিশ্বের বিভিন্ন দেশে শীত ও গ্রীষ্মের (কখন আদর্শ এবং দিবালোক সংরক্ষণের) সময় পরিবর্তন করতে (এবং কিনা) প্রায়শই শেষ মুহুর্তের পরিবর্তনগুলি মোকাবেলায় প্রতি বছর একাধিকবার আপডেট করা হয়। ২০০৯ সালে, সর্বশেষ প্রকাশটি ছিল ২০০৯; 2010 সালে, এটি 2010n ছিল; ২০১১ সালে, এটি ছিল 2011 এন; মে 2012 এর শেষে, মুক্তি ছিল 2012c 2012 দ্রষ্টব্য যে দুটি পৃথক সংরক্ষণাগারে (tzcode20xxy.tar.gz এবং tzdata20xxy.tar.gz) ডেটা এবং প্রকৃত টাইম জোন ডেটা নিজেই পরিচালনা করার জন্য কোডের একটি সেট রয়েছে। কোড এবং ডেটা উভয়ই পাবলিক ডোমেনে।

আমেরিকা / লস_এঞ্জেলিজ (এবং মার্কিন / প্যাসিফিকের সমার্থক শব্দ) এর মতো টাইম জোনের নামগুলির উত্স এটি।

আপনার যদি বিভিন্ন জোনের ট্র্যাক রাখতে হয় তবে আপনার ওলসন ডাটাবেস দরকার। অন্যরা যেমন পরামর্শ দিয়েছে, আপনিও একটি নির্দিষ্ট ফর্ম্যাটে ডেটা সঞ্চয় করতে চান - ইউটিসি সাধারণত টাইম জোনে যে ডেটা উত্পন্ন হয়েছিল তার রেকর্ড সহ - সাধারণত একটি চয়ন করা হয়। আপনি ইউটিসি থেকে সময় এবং সময় অঞ্চলের নাম থেকে অফসেটের মধ্যে পার্থক্য করতে চাইতে পারেন; যে পরে একটি পার্থক্য করতে পারেন। এছাড়াও, বর্তমানে এটি 2010-03-28T23: 47: 00-07: 00 (মার্কিন / প্রশান্ত মহাসাগর) জেনেও আপনাকে 2010-11-15T12: 30 - এর মান ব্যাখ্যা করতে বা সহায়তা করতে পারে না - যা সম্ভবত PST- এ নির্দিষ্ট করা হয়েছে ( প্যাসিফিক স্ট্যান্ডার্ড সময়) পিডিটি (প্যাসিফিক দিবালোক সংরক্ষণের সময়) এর চেয়ে বেশি।

স্ট্যান্ডার্ড সি লাইব্রেরি ইন্টারফেস ভয়ঙ্করভাবে এই ধরণের স্টাফ সঙ্গে সহায়ক নয়।

ওলসনের ডেটা স্থানান্তরিত হয়েছে, কিছু অংশে কারণ এডি ওলসন শিগগিরই অবসর নেবেন এবং কিছু অংশ হ'ল কপিরাইট লঙ্ঘনের জন্য রক্ষণাবেক্ষণকারীদের বিরুদ্ধে একটি (এখন বরখাস্ত) আইন মামলা ছিল। টাইম জোনের ডাটাবেস এখন আইএএনএ , ইন্টারনেট অ্যাসাইনড নাম্বার অথরিটি এর তত্ত্বাবধানে পরিচালিত হয়েছে এবং প্রথম পৃষ্ঠায় 'টাইম জোন ডাটাবেস'- এর একটি লিঙ্ক রয়েছে । আলোচনা মেলিংয়ের তালিকাটি এখন tz@iana.org; ঘোষণা তালিকা হয় tz-announce@iana.org।

— জনাথন লেফলার
সূত্র
12
ওলসন ডাটাবেসে historical তিহাসিক ডেটাও রয়েছে , যা এটি ডিএসটি পরিচালনার জন্য বিশেষভাবে দরকারী করে তোলে। উদাহরণস্বরূপ, এটি জানে যে মার্কিন যুক্তরাষ্ট্রে 31 মার্চ 2000 এর সাথে সম্পর্কিত একটি ইউটিসি মান ডিএসটিতে নেই, তবে মার্কিন যুক্তরাষ্ট্রে 31 মার্চ, ২০০৮ এর সাথে সম্পর্কিত একটি ইউটিসি মান।
— জোশ কেলি
3
ইউনিকোড কনসোর্টিয়াম ওলসন টোম জোন আইডি এবং উইন্ডোজ টাইম জোন আইডিগুলির মধ্যে একটি ম্যাপিং বজায় রাখে: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/…
— জোশ কেলি
ইউনিকোড কনসোর্টিয়ামের পৃষ্ঠার জন্য আপডেট লিঙ্ক: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/…
— স্প্যান
ওলসন ফাইলগুলি বিশ্লেষণ সম্পর্কিত তথ্য কোথায় পাওয়া যাবে? আমি এটি একটি ডিবি টেবিলের মধ্যে সংকলন করতে চাই, তবে কীভাবে ফাইলগুলি পড়তে হবে তা বুঝতে পারি না
— শিয়াটিয়েল
@ গিদিরিচ: মূল তথ্যটি ডেটা সহ পাওয়া যায় এবং এটি বোঝা সহজ নয়। এর জন্য মূল ডকুমেন্টেশন zic.8ম্যান পৃষ্ঠাতে (বা zic.8.txt) রয়েছে। আপনি প্রয়োজন হবে tzcode2011i.tar.gzবদলে ফাইল, বা ভাল হিসাবে হিসাবে, tzdata2011i.tar.gzফাইলটি এই তথ্য পেতে।
— জোনাথন লেফলার
26

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

মনে রাখবেন যে অফসেটটি সর্বদা ঘন্টা সংখ্যার পূর্ণসংখ্যার হয় না (যেমন ভারতীয় মানক সময়টি ইউটিসি + 05: 30)।

উদাহরণস্বরূপ, উপযুক্ত ফর্ম্যাটগুলি হ'ল টিউপল (ইউনিক্স সময়, মিনিটের মধ্যে অফসেট) বা আইএসও 8601 ।

— ওফ
সূত্র
5
প্রদর্শনের জন্য, অফসেটটি নিখুঁত। আপনি যদি পরিবর্তন করতে চান তবে অফসেটটি এখনও পর্যাপ্ত নয়। আপনাকে সময় অঞ্চলটিও জানতে হবে কারণ নতুন মানটির জন্য আলাদা অফসেটের প্রয়োজন হতে পারে।
— ম্যাট জনসন-পিন্ট
23

"কম্পিউটার টাইম" এবং "পিপল টাইম" এর সীমা অতিক্রম করা দুঃস্বপ্ন। প্রধানটি হ'ল সময় অঞ্চল এবং দিবালোক সংরক্ষণের সময় পরিচালনার নিয়মের জন্য কোনও ধরণের মানক নেই। দেশগুলি যে কোনও সময় তাদের সময় অঞ্চল এবং ডিএসটি বিধি পরিবর্তন করতে পারে এবং তারা তা করে।

কিছু দেশ যেমন ইস্রায়েল, ব্রাজিল, প্রতি বছর সিদ্ধান্ত নেয় যে তাদের দিবালোক সংরক্ষণের সময় কখন থাকবে, তাই কখন (যদি) ডিএসটি কার্যকর হবে তা আগেই জানা সম্ভব নয় impossible অন্যরা কখন ডিএসটি কার্যকর হয় সে সম্পর্কে নিয়ম স্থির করেছেন (ইস)। অন্যান্য দেশগুলি ডিএসটি সব হিসাবে ব্যবহার করে না।

জিএমটি থেকে সময় অঞ্চলগুলি পুরো সময়ের পার্থক্য রাখতে হবে না। নেপাল +5.45 হয়। এমন কি টাইমজোনগুলি রয়েছে যা +13 13 সেটার অর্থ হল:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

সব একই সময়, এখনও 3 বিভিন্ন দিন!

টাইমজোনগুলির সংক্ষিপ্তসারগুলিরও কোনও স্পষ্ট মান নেই এবং ডিএসটি-তে থাকাকালীন সেগুলি কীভাবে পরিবর্তিত হয় তাই আপনি এই জাতীয় জিনিসগুলি শেষ করে:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

সর্বোত্তম পরামর্শ হ'ল যথাসময়ে স্থানীয় সময় থেকে দূরে থাকুন এবং ইউটিসি যেখানে আপনি পারেন সেখানে আটকে যান। শুধুমাত্র শেষ সময়ে সম্ভব স্থানীয় মুহূর্তে রূপান্তর করুন।

পরীক্ষার সময় নিশ্চিত হয়ে নিন যে আপনি পশ্চিম এবং পূর্ব গোলার্ধের দেশগুলিকে পরীক্ষা করে ডিএসটি উভয়ই চলছে এবং না এমন একটি দেশ যা ডিএসটি ব্যবহার করে না (মোট 6)।

— রিচার্ড
সূত্র
ইস্রায়েল সম্পর্কে - এটি অর্ধেক সত্য। যদিও জুলিয়ান ক্যালেন্ডারে ডিএসটি পরিবর্তনের সময় নির্দিষ্ট তারিখ নয় - হিব্রু ক্যালেন্ডারের উপর ভিত্তি করে একটি নিয়ম রয়েছে (২০১৪ সালে একটি পরিবর্তন হয়েছিল)। যাইহোক, সাধারণ ধারণাটি সঠিক - এই জিনিসগুলি একবারে একবারে পরিবর্তিত হতে পারে
— ইয়ারন ইউ
1
এছাড়াও, এএসটি = আটলান্টিক স্ট্যান্ডার্ড সময়। 'সেরা পরামর্শ' হিসাবে, এটি সূচনা পয়েন্ট হিসাবে ঠিক আছে, তবে আপনাকে এই পৃষ্ঠাটির বাকী অংশটি পড়তে হবে এবং একটু প্রার্থনা করতে হবে এবং আপনি এটি কিছুক্ষণের জন্য সঠিকভাবে পেতে পারেন।
— ডেভিডওয়ালি
20

পিএইচপি জন্য:

পিএইচপি> 5.2-তে ডেটটাইমজোন ক্লাসটি ইতিমধ্যে ওলসন ডিবি-র উপর ভিত্তি করে তৈরি হয়েছে যা অন্যরা উল্লেখ করেছেন, সুতরাং আপনি যদি পিএইচপিতে টাইমজোন রূপান্তর করছেন এবং ডিবিতে না হন তবে আপনাকে (হার্ড-টু বোধগম্য) ওলসন ফাইলগুলির সাথে কাজ করার ছাড় দেওয়া হবে।

যাইহোক, পিএইচপি ওলসন ডিবি হিসাবে ঘন ঘন আপডেট হয় না, তাই কেবল পিএইচপি সময়সীমার রূপান্তরগুলি আপনাকে পুরানো ডিএসটি তথ্যের সাথে ছেড়ে দিতে পারে এবং আপনার ডেটার নির্ভুলতার উপর প্রভাব ফেলতে পারে। এটি প্রায়শই ঘটতে প্রত্যাশিত নয়, এটা ঘটতে পারে, এবং হবে যদি আপনি ব্যবহারকারীদের বৃহৎ বেস বিশ্বব্যাপী আছে ঘটে।

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

— শিয়ালিল
সূত্র
18

যদি আপনার নকশা এটি সমন্বয় করতে পারে তবে স্থানীয় সময় রূপান্তর সমস্ত একসাথে এড়িয়ে চলুন!

আমি কারও কাছে জানি এটি পাগল শোনায় তবে ইউএক্স সম্পর্কে চিন্তা করুন: ব্যবহারকারীরা এক নজরে নিরঙ্কুশ তারিখগুলির তুলনায় (আপাতত, গতকাল, আগামী সোমবার) নিকটবর্তী, আপেক্ষিক তারিখগুলি (আজ, গতকাল, আগামী সোমবার) প্রসেস করে। এবং আপনি যখন এটির বিষয়ে আরও চিন্তা করেন, তারিখের কাছাকাছি সময় অঞ্চলগুলির যথাযথতা (এবং ডিএসটি) আরও গুরুত্বপূর্ণ now(), সুতরাং আপনি যদি +/- 1 বা 2 সপ্তাহের জন্য আপেক্ষিক বিন্যাসে তারিখগুলি / তারিখের সময়গুলি প্রকাশ করতে পারেন তবে বাকি অংশগুলি তারিখগুলি ইউটিসি হতে পারে এবং এটি 95% ব্যবহারকারীর পক্ষে খুব বেশি গুরুত্বপূর্ণ।

আপনি ইউটিসিতে সমস্ত তারিখ সংরক্ষণ করতে পারেন এবং ইউটিসিতে আপেক্ষিক তুলনা করতে পারেন এবং কেবলমাত্র আপনার সম্পর্কিত তারিখের বাইরে ইউটিসি-র তারিখগুলি প্রদর্শন করতে পারেন।

এটি ব্যবহারকারীর ইনপুটটিতেও প্রয়োগ করতে পারে (তবে সাধারণত আরও সীমিত ফ্যাশনে)। কেবলমাত্র {গতকাল, আজ, আগামীকাল, পরের সোমবার, পরের বৃহস্পতিবার a থাকা একটি ড্রপ ডাউন থেকে নির্বাচন করা date একটি তারিখ চয়নকারের চেয়ে ব্যবহারকারীর পক্ষে অনেক সহজ এবং সহজ। তারিখ বাছাইকারীরা ফর্ম ফিলিংয়ের সবচেয়ে ব্যথা প্ররোচিত কিছু উপাদান। অবশ্যই এটি সব ক্ষেত্রে কার্যকর হবে না তবে আপনি দেখতে পাচ্ছেন যে এটি খুব শক্তিশালী করতে কেবল সামান্য চৌকস ডিজাইন লাগে।

— ম্যাট কোকাজ
সূত্র
16

যদিও আমি এটি চেষ্টা করে দেখিনি, টাইম জোনের সামঞ্জস্যের জন্য আমার কাছে আকর্ষণীয় মনে হবে এমন পদ্ধতি নিম্নরূপ হবে:

  1. ইউটিসিতে সবকিছু সংরক্ষণ করুন।

  2. TZOffsetsতিনটি কলাম সহ একটি সারণী তৈরি করুন : অঞ্চলক্লাসআইডি, স্টার্টডেটটাইম, এবং অফসেটমিনিটস (অন্তর্নিহিত কয়েক মিনিটের মধ্যে)।

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

আপনার যখন কোনও ইউটিসি সময়ের স্থানীয় সময় গণনা করতে হবে, কেবল এটি করুন:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

আপনি আপনার অ্যাপ্লিকেশনটিতে এই টেবিলটি ক্যাশে করতে চান এবং লিনকিউ বা অনুরূপ কিছু ব্যবহার করতে পারেন ডাটাবেসগুলিতে আঘাত না করে প্রশ্নগুলি করার জন্য।

এই ডেটা পাবলিক ডোমেন tz ​​ডাটাবেস থেকে নিঃসরণ করা যায় ।

এই পদ্ধতির সুবিধা এবং পাদটীকা:

  1. কোনও নিয়ম কোডে বেক করা হয় না, আপনি সহজেই নতুন অঞ্চল বা তারিখের সীমাগুলির জন্য অফসেটগুলি সামঞ্জস্য করতে পারেন।
  2. আপনাকে খেজুর বা অঞ্চলগুলির প্রতিটি সীমা সমর্থন করতে হবে না, আপনি প্রয়োজন হিসাবে এগুলি যুক্ত করতে পারেন।
  3. অঞ্চলগুলিকে ভূ-রাজনৈতিক সীমানার সাথে সরাসরি মিল রাখতে হবে না এবং সারিগুলির সদৃশতা এড়ানোর জন্য (উদাহরণস্বরূপ, মার্কিন যুক্তরাষ্ট্রের বেশিরভাগ রাজ্য একইভাবে ডিএসটি হ্যান্ডেল করে) আপনার আরও বিস্তৃত অঞ্চলক্লাসের এন্ট্রি থাকতে পারে যা অন্য টেবিলে আরও moreতিহ্যবাহী তালিকার সাথে লিঙ্ক করে link রাজ্য, দেশ, ইত্যাদি
  4. মার্কিন যুক্তরাষ্ট্রের মতো পরিস্থিতিতে যেখানে ডিএসটি শুরু এবং শেষের তারিখ গত কয়েক বছর ধরে পরিবর্তিত হয়েছে, এটি মোকাবেলা করা বেশ সহজ।
  5. যেহেতু স্টার্টডেটটাইম ক্ষেত্রটিও একটি সময় সঞ্চয় করতে পারে, তাই 2:00 এএম স্ট্যান্ডার্ড পরিবর্তন ওভার সময় সহজেই পরিচালনা করা হয়।
  6. বিশ্বের কোথাও কোথাও 1 ঘন্টা ডিএসটি ব্যবহার হয় না। এটি সহজেই এই মামলাগুলি পরিচালনা করে।
  7. ডেটা টেবিলটি ক্রস প্ল্যাটফর্ম এবং এটি একটি পৃথক ওপেন সোর্স প্রকল্প হতে পারে যা ডেভেলপাররা ব্যবহার করতে পারেন যারা প্রায় কোনও ডাটাবেস প্ল্যাটফর্ম বা প্রোগ্রামিং ভাষা ব্যবহার করেন।
  8. এটি অফসেটগুলির জন্য ব্যবহার করা যেতে পারে যাগুলির সময় অঞ্চলগুলির সাথে কোনও সম্পর্ক নেই। উদাহরণস্বরূপ, পৃথিবীর ঘূর্ণন, গ্রেগরিয়ান ক্যালেন্ডারের অভ্যন্তরে এবং এর মধ্যে historicalতিহাসিক সমন্বয় ইত্যাদির জন্য সময়-সময় ঘটে যাওয়া 1-সেকেন্ড সামঞ্জস্যতা
  9. যেহেতু এটি একটি ডাটাবেস টেবিলের মধ্যে রয়েছে, স্ট্যান্ডার্ড রিপোর্ট কোয়েরি ইত্যাদি ব্যবসায়িক লজিক কোডের মাধ্যমে ট্রিপ ছাড়াই ডেটার সুবিধা নিতে পারে।
  10. এটি টাইম জোন অফসেটগুলিও হ্যান্ডল করে যদি আপনি এটি চান এবং এমনকি এমন একটি বিশেষ casesতিহাসিক ক্ষেত্রেও জবাবদিহি করতে পারেন যেখানে কোনও অঞ্চলকে অন্য সময় অঞ্চলে নির্ধারিত করা হয়। আপনার যা দরকার তা হ'ল একটি প্রাথমিক তারিখ যা সর্বনিম্ন শুরুর তারিখের সাথে প্রতিটি অঞ্চলে অফসেট টাইম অঞ্চল নির্ধারণ করে। এর জন্য প্রতিটি টাইম জোনের জন্য কমপক্ষে একটি অঞ্চল তৈরি করা প্রয়োজন, তবে আপনাকে আকর্ষণীয় প্রশ্ন জিজ্ঞাসা করার অনুমতি দেবে: "১৯৮৯ সালের ২ শে ফেব্রুয়ারী সকাল 5 টা ৫০ মিনিটে ওয়াশিংটনের ইউমা, অ্যারিজোনা এবং সিয়াটলের মধ্যে স্থানীয় সময়ের মধ্যে পার্থক্য কী?" (অন্যটি থেকে কেবল একটি SUM () বিয়োগ করুন)।

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

— রিচার্ডাল্টলেন্ট
সূত্র
8
আপনার ডাটাবেস ধারণা ইতিমধ্যে ওলসন ডেটাবেস হিসাবে প্রয়োগ করা হয়েছে। যদিও দিবালোক সঞ্চয় সময় দিবালোক নির্দিষ্ট সময় অঞ্চল নির্দিষ্ট করে একটি ওভারল্যাপ তৈরি করে সমস্যাটি সমাধানে সহায়তা করতে পারে। 2:15 EST এবং 2: 15 EDT বিভিন্ন সময় are অন্যান্য পোস্টে উল্লেখ করা হিসাবে অফসেট নির্দিষ্ট করে অস্পষ্টতাও সমাধান করে।
— বিলথোর
5
আপনার নিজস্ব ডাটাবেস রাখার ক্ষেত্রে বড় সমস্যা এটি আপডেট করে রাখা। ওলসন এবং উইন্ডোজ আপনার জন্য রক্ষণাবেক্ষণ করা হয়। আমার কাছে খারাপ ডিএসটি ট্রানজিশন হওয়ার একাধিক মামলা রয়েছে কারণ টেবিলগুলি পুরানো। এগুলি পুরোপুরি ছিটকে ফেলা এবং ফ্রেমওয়ার্ক বা ওএস স্তরের ডাটাবেসের উপর নির্ভর করা অনেক বেশি নির্ভরযোগ্য।
— ম্যাট জনসন-পিন্ট
4
আপনার নিজস্ব ডাটাবেস তৈরি করবেন না : সর্বদা সিস্টেমের এপিআইতে নির্ভর করুন!
— অ্যালেক্স
15

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

এটি সম্ভবত আমার জাভাস্ক্রিপ্ট কোডটির সাথে ক্লায়েন্টটিতে স্ট্রিং হিসাবে ক্লায়েন্টে ফিরে পোস্ট করার জন্য তারিখ তৈরি করেছিল, কারণ জাভাস্ক্রিপ্ট সময় অঞ্চল এবং দিবালোক সঞ্চয়ের জন্য সামঞ্জস্য করছিল, এবং কিছু ব্রাউজারে কখন দিবালোকের সঞ্চয় প্রয়োগ করার জন্য গণনা ছিল for অন্যের চেয়ে আলাদা বলে মনে হয়েছিল।

শেষ পর্যন্ত আমি ক্লায়েন্টের পুরোপুরি তারিখ এবং সময় গণনাগুলি সরিয়ে ফেলার অপশনটি বেছে নিয়েছিলাম এবং ধারাবাহিক রূপান্তরকরণের অনুমতি দেওয়ার জন্য আমার সার্ভারে একটি পূর্ণসংখ্যা কীতে পোস্ট করেছি then

এগুলি থেকে আমার শেখা: ওয়েব অ্যাপ্লিকেশনগুলিতে জাভাস্ক্রিপ্টের তারিখ এবং সময় গণনাগুলি ব্যবহার করবেন না যতক্ষণ না আপনার একেবারে প্রয়োজন।

— জুন oon
সূত্র
জাভাস্ক্রিপ্ট সার্ভার মেশিনে নয়, ক্লায়েন্ট মেশিনে চলে। জাভাস্ক্রিপ্টের বেস ডেটটাইম ক্লায়েন্টের ডেটটাইম, সার্ভারের ডেটটাইম নয়।
— বালুস সি
হাই বালুসি। আমি এটি বুঝতে পারি (আমার মূল পোস্ট থেকে: "ক্লায়েন্টের জাভাকোড স্ক্রিপ্ট যা তারিখটি তৈরি করেছে ...")। আমার সমস্যাটি হ'ল নির্দিষ্ট ক্লায়েন্ট মেশিনটি এক উপায়ে ডিএসটি প্রক্রিয়াকরণ করে এবং কিছু অন্যকে অন্যভাবে। তাই ব্রাউজারের অদ্ভুততা রোধ করার জন্য আমি সেই সমস্ত প্রসেসিং সার্ভার-সাইড সরিয়ে নিয়েছি
— জুন
@ জুন — এবং জাভাস্ক্রিপ্ট বাস্তবায়নগুলিতে এমন বাগ রয়েছে যা আপনি সনাক্ত করতে পারবেন না বা অনুমতি দিতে পারবেন না। সুতরাং হ্যাঁ, বিষয়গুলির জন্য কখনই ক্লায়েন্ট-পাশের ECMAScript তারিখ গণনা ব্যবহার করবেন না (যদিও আপনি অন্যথায় খুব ভাল কাজ করতে পারেন)।
— রবজি
14

আমি এটি দুটি ধরণের সিস্টেমে আঘাত করেছি, "শিফট প্ল্যানিং সিস্টেমগুলি (যেমন কারখানার শ্রমিক)" এবং "গ্যাস নির্ভর পরিচালন ব্যবস্থা) ..."

23 এবং 25 ঘন্টা দীর্ঘ দিনগুলি হ'ল একটি ব্যথা, তাই 8 ঘন্টা শিফটগুলি 7hr বা 9 ঘন্টা হয়। সমস্যাটি হ'ল আপনি দেখতে পাবেন যে প্রতিটি গ্রাহক, এমনকি গ্রাহকের বিভাগেরও তারা এই বিশেষ ক্ষেত্রে কী করেন সে সম্পর্কে তারা প্রায়শই নথিপত্র তৈরি না করে তৈরি করেছেন rules

আপনার "শেল্ফ বন্ধ" সফ্টওয়্যারটির জন্য অর্থ প্রদান না করা অবধি গ্রাহকের কাছে কিছু প্রশ্ন সবচেয়ে ভাল জিজ্ঞাসা করা হয় না। সফ্টওয়্যার কেনার সময় এমন কোনও গ্রাহক খুঁজে পাওয়া খুব বিরল যে এই ধরণের ইস্যু সম্পর্কে চিন্তা করে।

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

— আয়ান রিংরোজ
সূত্র
6
আমার বান্ধবী, একজন নার্স, রাতে কাজ করেন এবং তাদের ডিএসটি সুইচওভার চলাকালীন সময় অঞ্চল লিখতে হয়। উদাহরণস্বরূপ, 2 এএম সিএসটি বনাম 2 এএম সিডিটি
— জো ফিলিপস
1
হ্যাঁ, এটি সাধারণ: আপনি যখন কোনও দৈনিক গড় (নাগরিক) গণনা করেন, আপনাকে 23, 24 বা 25 ঘন্টা সময় সহ্য করতে হয়। ফলস্বরূপ, আপনি যখন 1 দিন গণনা করেন এটি 24 ঘন্টা যুক্ত হয় না ! দ্বিতীয়ত, আপনার নিজের সময় অঞ্চল কোড তৈরি করার চেষ্টা করবেন না; কেবল সিস্টেম এপিআই ব্যবহার করুন। আপ-টু-ডেট টাইমজোন ডাটাবেস পেতে প্রতিটি মোতায়েন করা সিস্টেম আপডেট করতে ভুলবেন না ।
— অ্যালেক্স
12

ওয়েবের জন্য, বিধিগুলি এত জটিল নয় ...

  • সার্ভার-সাইড, ইউটিসি ব্যবহার করুন
  • ক্লায়েন্ট-সাইড, ওলসন ব্যবহার করুন
    • কারণ: ইউটিসি-অফসেটগুলি দিবালোক সঞ্চয়-নিরাপদ নয় (উদাঃ নিউ ইয়র্ক ইএসটি (ইউটিসি - 5 ঘন্টা) বছরের অংশ, ইডিটি (ইউটিসি - 4 ঘন্টা) বছরের বাকি অংশ)।
    • ক্লায়েন্ট-পার্শ্ব সময় অঞ্চল নির্ধারণের জন্য, আপনার কাছে দুটি বিকল্প রয়েছে:

বাকিটি আপনার সার্ভার-সাইড ডেটটাইম লাইব্রেরিগুলি ব্যবহার করে কেবল ইউটিসি / স্থানীয় রূপান্তর। যেতে ভাল ...

— রেভ ইয়ারিন
সূত্র
2
এটি একটি সূচনা পয়েন্ট হিসাবে ভাল পরামর্শ, কিন্তু এটি সম্পূর্ণরূপে প্রয়োগের উপর নির্ভর করে। এটি একটি বন্ধুত্বপূর্ণ ওয়েবসাইটের জন্য ভাল হতে পারে তবে আপনার আবেদনে যদি কোনও আইনি / এখতিয়ার / আর্থিক দিক থাকে যে কেউ মামলা করতে পারে (আমি বেশ কয়েকটি ক্ষেত্রে কাজ করেছি), তবে এটি একটি অতি-সরলকরণ কারণ বিভিন্ন ধরণের রয়েছে ' সময় ', যেমন এই পৃষ্ঠায় অন্য কোথাও উল্লেখ করা হয়েছে।
— ডেভিডওয়ালি
12

ওয়েব সাইট এবং অন্যান্য ব্যাক-এন্ড পরিষেবাদিসমূহ সহ সার্ভারে চলমান অ্যাপ্লিকেশনগুলির ক্ষেত্রে , সার্ভারের সময় অঞ্চল সেটিংটি অ্যাপ্লিকেশন দ্বারা উপেক্ষা করা উচিত।

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

ওয়েব সাইটগুলি সহ সার্ভার-সাইড কোডের দ্বারা সার্ভারের স্থানীয় সময় অঞ্চলটি বিশেষত কোনও কিছুর আশা করা উচিত নয় ।

কিছু ভাষায়, স্থানীয় সময় অঞ্চলটি সহজেই অ্যাপ্লিকেশন কোডে প্রবেশ করতে পারে। উদাহরণস্বরূপ, DateTime.ToUniversalTime.NET পদ্ধতি রূপান্তর করবে থেকে ইউটিসি স্থানীয় সময় জোন, এবং DateTime.Nowসম্পত্তি স্থানীয় সময় অঞ্চলে বর্তমান সময় ফেরৎ। এছাড়াও, Dateজাভাস্ক্রিপ্টে নির্মাণকারী কম্পিউটারের স্থানীয় সময় অঞ্চল ব্যবহার করে uses এরকম আরও অনেক উদাহরণ রয়েছে। কম্পিউটারের স্থানীয় সময় অঞ্চল সেটিং ব্যবহার করে এমন কোনও কোড এড়ানো প্রতিরক্ষামূলক প্রোগ্রামিং অনুশীলন করা গুরুত্বপূর্ণ।

ক্লায়েন্ট-সাইড কোড, যেমন ডেস্কটপ অ্যাপ্লিকেশন, মোবাইল অ্যাপ্লিকেশন এবং ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের জন্য স্থানীয় সময় অঞ্চল ব্যবহার করে সংরক্ষণ করুন।

— ম্যাট জনসন-পিন্ট
সূত্র
11

আপনার সার্ভারগুলিকে ইউটিসিতে সেট করা রাখুন এবং নিশ্চিত করুন যে সেগুলি সমস্ত এনটিপি বা সমমানের জন্য কনফিগার করা আছে।

ইউটিসি দিবালোকের সঞ্চয় সময় সময় সমস্যাগুলি এড়িয়ে যায় এবং সিঙ্কের বাইরে থাকা সার্ভারগুলি অনির্দেশ্য ফলাফলের কারণ হতে পারে যা নির্ণয়ে কিছুটা সময় নেয়।

— অ্যান্ড্রু বি
সূত্র
9

FAT32 ফাইল সিস্টেমে সঞ্চিত টাইমস্ট্যাম্পগুলির সাথে কাজ করার সময় সাবধানতা অবলম্বন করুন - এটি সর্বদা স্থানীয় সময় স্থানাঙ্কে স্থির থাকে (যার মধ্যে ডিএসটি অন্তর্ভুক্ত থাকে - এমএসডিএন নিবন্ধ দেখুন )। ওটার উপরে জ্বলে উঠল।

— paquetp
সূত্র
দুর্দান্ত পয়েন্ট। এনটিএফএসের এই সমস্যা নেই, তবে কিছু লোক এখনও FAT32 ব্যবহার করে - বিশেষত ইউএসবি কীগুলিতে।
— ম্যাট জনসন-পিন্ট
7

অন্য একটি জিনিস, এটি নিশ্চিত করুন যে সার্ভারগুলিতে আপ ডেটলাইট সঞ্চয় প্যাচ প্রয়োগ হয়েছে।

আমরা গত বছর এমন পরিস্থিতিতে পড়েছিলাম যেখানে উত্তর আমেরিকার ব্যবহারকারীদের জন্য তিন সপ্তাহের জন্য আমাদের সময়গুলি এক ঘন্টার মধ্যে অবিচ্ছিন্নভাবে শেষ হয়ে যায়, যদিও আমরা ইউটিসি ভিত্তিক সিস্টেমটি ব্যবহার করি।

শেষ পর্যন্ত দেখা যাচ্ছে এটি সার্ভার ছিল। তাদের কেবলমাত্র একটি আপ-টু-ডেট প্যাচ প্রয়োগ করা হয়েছিল ( উইন্ডোজ সার্ভার 2003 )।

— সলিয়াদ
সূত্র
6

পিএইচপি এর DateTimeZone::listAbbreviations()আউটপুট

এই পিএইচপি পদ্ধতিটি কিছু 'মেজর' টাইমজোন (সিইএসটি এর মতো) সমন্বিত একটি সংঘবদ্ধ অ্যারে প্রদান করে, যা তাদের নিজস্বটিতে আরও নির্দিষ্ট 'ভৌগলিক' টাইমজোনগুলি রয়েছে (যেমন ইউরোপ / আমস্টারডাম)।

আপনি যদি এই সময় অঞ্চল এবং তাদের অফসেট / ডিএসটি তথ্য ব্যবহার করেন তবে নিম্নলিখিতটি উপলব্ধি করা অত্যন্ত গুরুত্বপূর্ণ:

দেখে মনে হচ্ছে প্রতিটি টাইমজোনের সমস্ত অফসেট / ডিএসটি কনফিগারেশন (historical তিহাসিক কনফিগারেশন সহ) অন্তর্ভুক্ত রয়েছে!

উদাহরণস্বরূপ, ইউরোপ / আমস্টারডাম এই ফাংশনটির আউটপুটে ছয়বার পাওয়া যাবে। দুটি ঘটনা (অফসেট 1172/4772) আমস্টারডাম সময়ের জন্য 1937 সাল পর্যন্ত ব্যবহৃত হয়; দুটি (1200/4800) সেই সময়ের জন্য যা 1937 এবং 1940 এর মধ্যে ব্যবহৃত হয়েছিল; এবং দুটি (3600/4800) 1940 সাল থেকে ব্যবহৃত সময়ের জন্য।

অতএব, আপনি বর্তমানে সঠিক / ব্যবহারের হিসাবে এই ফাংশন দ্বারা ফিরিয়ে দেওয়া অফসেট / ডিএসটি তথ্যের উপর নির্ভর করতে পারবেন না !

আপনি যদি একটি নির্দিষ্ট টাইমজোনটির বর্তমান অফসেট / ডিএসটি জানতে চান তবে আপনাকে এই জাতীয় কিছু করতে হবে:

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>
— জনাথন
সূত্র
5

আপনি যদি ডিএসটি সক্রিয় সাথে চলমান ডাটাবেস সিস্টেমগুলি বজায় রাখার জন্য হয়ে থাকেন তবে শরত্কালে সংক্রমণের সময় সেগুলি বন্ধ করে দেওয়া দরকার কিনা তা সাবধানতার সাথে পরীক্ষা করে দেখুন। ম্যান্ডি ডিবিএস (বা অন্য সিস্টেমগুলি) একই পয়েন্টটি (স্থানীয়) সময়ে দু'বার পাস করতে পছন্দ করে না, যখন আপনি শরত্কালে ঘড়ির কাঁটা পিছনে ঘুরিয়ে দেন ঠিক তখনই এটি ঘটে। এসএপি একটি (আইএমএইচও সত্যই ঝরঝরে) কাজের সাথে এটি সমাধান করেছে - ঘড়ির পিছনে ফিরার পরিবর্তে তারা কেবলমাত্র অভ্যন্তরীণ ঘড়িটিকে আধ ঘন্টার স্বাভাবিক গতিতে চালিয়ে দেয় ...

— vwegert
সূত্র
4

আপনি কি .NET ফ্রেমওয়ার্ক ব্যবহার করছেন ? যদি তা হয় তবে আমাকে .NET 3.5 এর সাথে যুক্ত ডেটটাইম অফসেট টাইপের সাথে আপনাকে পরিচয় করিয়ে দিন ।

এই কাঠামোটি একটি DateTimeএবং অফসেট ( TimeSpan) উভয়ই ধারণ করে , যা DateTimeOffsetউদাহরণের তারিখ এবং সময় এবং সমন্বিত ইউনিভার্সাল সময় (ইউটিসি) এর মধ্যে পার্থক্য নির্দিষ্ট করে ।

  • DateTimeOffset.Nowস্ট্যাটিক পদ্ধতি ফিরে আসবে DateTimeOffset বর্তমান (স্থানীয়) সময় গঠিত উদাহরণস্বরূপ, এবং স্থানীয় অফসেট (যেমন অপারেটিং সিস্টেম এর আঞ্চলিক তথ্য সংজ্ঞায়িত)।

  • DateTimeOffset.UtcNowস্ট্যাটিক পদ্ধতি ফিরে আসবে DateTimeOffsetইউটিসি বর্তমান সময় গঠিত উদাহরণস্বরূপ (যেন আপনি গ্রীনিচ ছিল)।

অন্যান্য সহায়ক ধরণের হ'ল টাইমজোন এবং টাইমজোনআইএনফো ক্লাস।

— এম এ হানিন
সূত্র
এটি উপস্থাপিত সমস্যার সমাধান নয়।
— ক্যারাদ্রি
4

.NET- এ এইগুলির জন্য যারা লড়াই করছেন তাদের জন্য দেখুন DateTimeOffsetএবং / অথবা TimeZoneInfoআপনার কিছুটা মূল্যবান কিনা ।

আপনি যদি আইএএনএ / ওলসন সময় অঞ্চল ব্যবহার করতে চান বা অন্তর্নির্মিত প্রকারগুলি আপনার প্রয়োজনের জন্য পর্যাপ্ত নয়, নোডা সময়টি দেখুন , যা .NET এর জন্য আরও স্মার্ট তারিখ এবং সময় API দেয়।

— ম্যাট জনসন
সূত্র
4

ব্যবসায়ের নিয়মগুলি সর্বদা নাগরিক সময় নিয়ে কাজ করা উচিত (যদি না আইন না থেকে থাকে তবে)। সচেতন থাকুন যে নাগরিক সময় একটি জগাখিচুড়ি, তবে এটি লোকেদের ব্যবহার তাই এটি গুরুত্বপূর্ণ।

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

— বেসিল বোর্কে
সূত্র
3
এখানে সমস্যা হ'ল সিভিল টাইম (ওরফে ক্যালেন্ডার সময়) সময়কালে একটি মুহুর্ত সঠিকভাবে উপস্থাপন করে না। আপনি যদি দ্বিতীয় যুগের পর্বগুলি গ্রহণ করেন, তবে আপনি কি সত্যই প্রতিটি মুহুর্তের জন্য অ্যাকাউন্ট করতে যাচ্ছেন যা দিবালোকের সঞ্চয় স্থানান্তরকে ছাড়িয়ে গেছে বা পুনরুদ্ধার করেছিল? সম্ভবত না. যুগের ভিত্তি কেবল ইউটিসি বা অন্য কিছু স্থির, তাত্ক্ষণিক-সময় রেফারেন্সের বিরুদ্ধে কাজ করে।
— ম্যাট জনসন-পিন্ট
@ ম্যাটজহানসন সুতরাং "ব্যবসায়িক বিধি" অংশ। নিয়মগুলি যদি বলে যে সকাল 2:30 টায় কিছু ঘটেছিল (বা যে কোনও সময়), এটি বছরের এক দিন দু'বার ঘটবে এবং বছরের একদিন কখনও হবে না। গ্রাহক যদি নিয়মটি স্পষ্ট না করেন তবে ঘটবে এমনটাই প্রত্যাশা ।
— ব্যবহারকারী 253751
নাগরিক সময়ে অভ্যন্তরীণ টাইমস্ট্যাম্পগুলি রাখা খুব জটিল হতে পারে। একটি যুগের পর থেকে এটি কয়েক সেকেন্ড হিসাবে চালিয়ে যাওয়া আরও জটিল, আমি একেবারে বিপদজনক বলব। আমি নিশ্চিত যে লোকেরা এটি করছে, এবং আপনি যদি খুব যত্নবান হন তবে বেশিরভাগ সময় এটি সঠিকভাবে কাজ করা সম্ভব হতে পারে তবে এটি সেরা অভ্যাস বা সাধারণ প্রস্তাব হিসাবে বিবেচনা করা যায় না।
— স্টিভ সামিট
2

কেবল দুটো বিষয়কেই নির্দেশ করতে চেয়েছিলাম যা ভুল বা কমপক্ষে বিভ্রান্ত বলে মনে হচ্ছে:

দিব্যরক্ষা সঞ্চয় দ্বারা প্রভাবিত হয় না এমন একটি ইউনিফাইড মান অনুযায়ী সর্বদা সময় চালিয়ে যান। জিএমটি এবং ইউটিসির বিভিন্ন ব্যক্তি উল্লেখ করেছেন, যদিও ইউটিসি প্রায়শই উল্লেখ করা হয় বলে মনে হয়।

প্রায় (প্রায়) সমস্ত ব্যবহারিক কম্পিউটিং উদ্দেশ্যে, ইউটিসি আসলে জিএমটি is আপনি যদি কোনও ভগ্নাংশের দ্বিতীয় সহ টাইমস্ট্যাম্প না দেখেন, আপনি GMT এর সাথে কাজ করছেন যা এই পার্থক্যটিকে অপ্রয়োজনীয় করে তোলে।

টাইমস্ট্যাম্পগুলি সংরক্ষণ করার সময় স্থানীয় সময় অফসেটটি (ডিএসটি অফসেট সহ) অন্তর্ভুক্ত করুন।

একটি টাইমস্ট্যাম্প সর্বদা GMT তে প্রতিনিধিত্ব করা হয় এবং এর ফলে অফসেট থাকে না।

— অ্যালিক্স এক্সেল
সূত্র
1
স্থানীয় সময় অফসেট আপনাকে ইভেন্টের মূল "প্রাচীর সময়" পুনরায় তৈরি করতে দেয়। আপনি যদি এই অতিরিক্ত ক্ষেত্রটি সংরক্ষণ না করেন তবে এই ডেটাটি হারাবে।
— নোগ্রিডব্যাগ
হ্যাঁ, ইউটিসি এবং জিএমটি বাদে অফসেটগুলি বিপরীত। উদাহরণস্বরূপ ইউটিসি -0700 GMT + 0700 এর সমান। সত্যিই, ডিজিটাল সমস্ত কিছু এই দিনগুলিতে ইউটিসি ব্যবহার করা উচিত।
— ম্যাট জনসন-পিন্ট
1
@ ম্যাট: আপনি ইউটিসি এবং জিএমটি অফসেটগুলি বিপরীতমুখী হওয়ার বিষয়ে নিশ্চিত? আমি কোথায় পড়তে পারি?
— রেটো হেনার
আসলে, আমি মনে করি আমি আগে ভুল ছিল। জিএমটি এবং ইউটিসি নিজেই উল্টে যায় না। এটি এমন কিছু বাস্তবায়ন রয়েছে যা এগুলিকে বিপরীত দিকে দেখায় যেমন আইএএনএ / ওলসন / টিজেডডিবি ডাটাবেস। এখানে দেখুন । বিপরীতে আপনি অফসেটগুলি দেখতে পাবেন এমন অন্য একটি অঞ্চলটি জাভাস্ক্রিপ্টের getTimezoneOffset () ফাংশনে রয়েছে।
— ম্যাট জনসন-পিন্ট
@ ম্যাট জনসন: এগুলি হ্যাক এবং এগুলি বাতিল করা উচিত।
— অ্যালিক্স অ্যাক্সেল
2

আমার অভিজ্ঞতা এখানে:

(কোনও তৃতীয় পক্ষের লাইব্রেরির প্রয়োজন নেই)

  • সার্ভার-সাইডে, ইউটিসি ফর্ম্যাটে সময়গুলি সংরক্ষণ করুন যাতে ব্যবহারকারী, সার্ভার, টাইমজোন বা ডিএসটি নির্বিশেষে ডাটাবেসে সমস্ত তারিখ / সময় মান একক মানের মধ্যে থাকে।
  • ইউআই স্তর বা ব্যবহারকারীর কাছে প্রেরিত ইমেলগুলিতে আপনাকে ব্যবহারকারী অনুসারে সময় দেখাতে হবে। এই বিষয়টির জন্য, আপনার ব্যবহারকারীর টাইমজোনটি অফসেট করা দরকার যাতে আপনি এই অফসেটটি আপনার ডাটাবেসের ইউটিসি মানটিতে যুক্ত করতে পারেন যা ব্যবহারকারীর স্থানীয় সময় হতে পারে। তারা হয় সাইন আপ করার সময় আপনি ব্যবহারকারীর টাইমজোন অফসেট নিতে পারেন বা আপনি ওয়েব এবং মোবাইল প্ল্যাটফর্মগুলিতে সেগুলি স্বয়ংক্রিয়ভাবে সনাক্ত করতে পারেন। ওয়েবসাইটগুলির জন্য, জাভাস্ক্রিপ্টের ফাংশন getTimezoneOffset () পদ্ধতিটি 1.0 সংস্করণ থেকে একটি স্ট্যান্ডার্ড এবং সমস্ত ব্রাউজারের সাথে সামঞ্জস্যপূর্ণ। (রেফার: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )
— ডক
সূত্র
আপনি ডিএসটি পরিবর্তনগুলি বিবেচনা করলে এটি কার্যকর হয় না। getTimezoneOffsetআপনি যে তারিখ এবং সময়ের সাথে কল করবেন তার অফসেট ফেরত দেয়। কোনও টাইম জোন যখন দিনের আলো সংরক্ষণের সময় বা বাইরে চলে যায় তখন অফসেটটি পরিবর্তন করতে পারে। টাইমজোন ট্যাগ উইকিতে "টাইম অঞ্চল! = অফসেট" দেখুন ।
— ম্যাট জনসন-পিন্ট
1
যদি আপনি "10:00 টায় কিছু করুন" এর মতো অ্যালার্ম সঞ্চয় করতে চান তবে আপনি এটি ইউটিসি তে সংরক্ষণ করতে পারবেন না, কারণ ডিএসটি শিফট। আপনার অবশ্যই এটি স্থানীয় সময়ের সাথে তুলনামূলকভাবে সঞ্চয় করতে হবে।
— অ্যালেক্স
2

কম্পিউটারফিল চ্যানেলে ইউটিউবে টাইমজোনগুলি সম্পর্কে টম স্কটের ভিডিওতে বিষয়টির একটি সুন্দর এবং বিনোদনমূলক বর্ণনা রয়েছে। উদাহরণ অন্তর্ভুক্ত:

  • সামোয়া (প্রশান্ত মহাসাগরের একটি দ্বীপ) অস্ট্রেলিয়া এবং নিউজিল্যান্ডের সাথে বাণিজ্য সহজ করার জন্য তার সময় অঞ্চলটিকে 24 ঘন্টা এগিয়ে নিয়েছে,
  • পশ্চিম তীরে , যেখানে 2 জনসংখ্যার লোক বিভিন্ন সময় অঞ্চল অনুসরণ করে,
  • 18 শতকের জুলিয়ান ক্যালেন্ডার থেকে গ্রেগরিয়ান ক্যালেন্ডারে পরিবর্তিত হয়েছে (যা রাশিয়ায় 20 শতকে হয়েছিল) happened
— আতিলা তানই
সূত্র
1

প্রকৃতপক্ষে, কার্নেল 32.dll সিস্টেমটাইমটোটোজস্পিফিকাল লোকেশন রফতানি করে না। তবে এটি নিম্নলিখিত দুটি রফতানি করে: সিস্টেমটাইমটোটোজসস্পেকিফিকলোকালটাইম এবং টিজেস্পিফিসিফিকলোক্যালটাইমটাইমসোস্টিমটাইম ...

— সরু চেপটা পেরেক-বিশেষ
সূত্র
1

কখনই কেবল নির্মাণকারীদের উপর নির্ভর করবেন না 

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

ডিএসটি-র কারণে নির্দিষ্ট তারিখের সময় না থাকলে তারা ব্যতিক্রম ছুঁড়ে ফেলতে পারে। পরিবর্তে, এই জাতীয় তারিখগুলি তৈরি করার জন্য আপনার নিজস্ব পদ্ধতি তৈরি করুন। সেগুলিতে, ডিএসটি কারণে ঘটে যাওয়া যে কোনও ব্যতিক্রম ধরা পড়ুন এবং ট্রান্সফিশনের অফসেটের সাথে প্রয়োজনীয় সময়টি সামঞ্জস্য করুন। টাইমজোন অনুযায়ী ডিএসটি বিভিন্ন তারিখে এবং বিভিন্ন সময়ে (ব্রাজিলের মধ্যরাতে এমনকি) ঘটতে পারে।

— সেবি
সূত্র
1

পরিচালনা করার সময়কে প্রমাণ করার জন্য একটি মাত্র উদাহরণ হ'ল বর্ণিত বিশাল জগাখিচুড়ি, এবং আপনি কখনই সন্তুষ্ট হতে পারবেন না। এই পৃষ্ঠায় বেশ কয়েকটি দাগে লিপ-সেকেন্ড এড়ানো হয়েছে।

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

আমি মনে করি এটি তখন থেকে ঠিক হয়ে গেছে, তবে কখনই জানতে পারবেন না যে এই 'ছোটখাটো বিবরণ' কখন আপনাকে পীড়িত করবে।

— DavidWalley
সূত্র
1
  • কখনই না, স্থানীয় সময়টিকে তার ইউটিসি অফসেট ছাড়াই (বা টাইম জোনের একটি রেফারেন্স) সংরক্ষণ করুন store এটি কীভাবে করবেন না তার উদাহরণ FAT32 এবং struct tmসি-তে অন্তর্ভুক্ত রয়েছে ¹
  • বুঝতে হবে যে একটি সময় অঞ্চল একটি সংমিশ্রণ
    • ইউটিসি অফসেটের একটি সেট (যেমন শীতে +0100, গ্রীষ্মে +0200)
    • যখন স্যুইচওভারটি ঘটে তার নিয়মগুলি (যা সময়ের সাথে সাথে পরিবর্তিত হতে পারে: উদাহরণস্বরূপ, 1990 এর দশকে EU মার্চ এবং অক্টোবরের শেষ রবিবার হিসাবে সুইচওভারকে সুরেলা করে দিয়েছিল সময়কাল 02:00 স্ট্যান্ডার্ড সময় / 03: 00 ডিএসটি; পূর্বে এটি ভিন্ন ছিল) সদস্য দেশগুলির মধ্যে)।

¹ কিছু বাস্তবায়ন struct tmইউটিসি অফসেট সংরক্ষণ করে তবে এটি এটি স্ট্যান্ডার্ড হিসাবে তৈরি করে নি।

— user149408
সূত্র
-4

ডাটাবেসগুলির সাথে ডিল করার ক্ষেত্রে (বিশেষত মাইএসকিউএল , তবে এটি বেশিরভাগ ডাটাবেসের ক্ষেত্রে প্রযোজ্য), ইউটিসি সংরক্ষণ করা আমার পক্ষে কঠিন মনে হয়েছিল।

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

আমি কেবল ডাটাবেসে সার্ভারের ডেটটাইম সংরক্ষণ করা সহজ করে পেয়েছি, তারপরে ডাটাবেসটি সঞ্চিত তারিখের সময়টিকে এসটিউএল স্টেটমেন্টগুলিতে ইউটিসিতে (অর্থাৎ UNIX_TIMESTAMP ()) রূপান্তর করতে দিন। এর পরে আপনি ডেটটাইমটিকে আপনার কোডটিতে ইউটিসি হিসাবে ব্যবহার করতে পারেন।

আপনার যদি সার্ভার এবং সমস্ত কোডের উপর 100% নিয়ন্ত্রণ থাকে তবে সম্ভবত সার্ভারের টাইমজোনটিকে ইউটিসিতে পরিবর্তন করা ভাল।

— মার্টিজন সিএমটি
সূত্র
স্থানীয় সময় (সার্ভারের সময়) "ফ্যাল-ব্যাক" স্টাইলের ডাইটালাইট সঞ্চয়ী ট্রানজিশনের সময় অস্পষ্ট হতে পারে। আপনি বর্ণিত হিসাবে এটি নির্ভরযোগ্য নয়। একাধিক ইউটিসি সময় থাকতে পারে যে সার্ভারের স্থানীয় সময় প্রতিনিধিত্ব করতে পারে।
— ম্যাট জনসন-পিন্ট
স্থানীয় সময়টি পুরোপুরি ঠিক আছে যদি সার্ভারটি একটি সান টাইম জোনে অবস্থিত, যেমন একটি যা ডিএসটি করে না।
— সায়েপ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.