অনলাইনে ইভেন্টগুলির জন্য সময় প্রদর্শনের জন্য উপযুক্ত সময় অঞ্চলটি কী?


11

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

ক্লায়েন্টদের টাইম জোনের উপর ভিত্তি করে সময়কে স্থানীয়করণের উপযুক্ত পদ্ধতি কি? ইউটিসি / জিএমটি ব্যবহার করবেন?

ধন্যবাদ

উত্তর:


4

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

বেশিরভাগ ওয়েবসাইট এই সমস্যা সমাধানের জন্য দুটি ভিন্ন সমাধানের মধ্যে একটি বেছে নেয়:

1) ডাটাবেসে ইউটিসি হিসাবে যে কোনও তারিখ জড়িত কোনও কিছু সংরক্ষণ করুন ... এবং আপনার ওয়েবসাইটের ব্যবহারকারীদের জন্য তারা কী টাইমজোন রাখছেন তা চয়ন করার জন্য কোনও ব্যবহারকারী-সংজ্ঞায়িত সেটিংকে অনুমতি দিন ... বা কিছু জিও-আইপি-লুকিং যাদু করার জন্য বিশ্বে তারা কোথায় এবং উপযুক্ত সময় অঞ্চলটি খুঁজে বার করে ... এবং তারপরে প্রতিবার আপনি তারিখটি প্রদর্শন করবেন ... স্থানীয়করণের জন্য যা কিছু ফাংশন প্রয়োজন তা কল করতে ভুলবেন না। প্রায় প্রতিটি প্রোগ্রামিং ভাষার একটি নির্দিষ্ট সময় অঞ্চল ব্যবহার করে তারিখগুলি প্রদর্শনের জন্য কিছু পদ্ধতি থাকে। তারিখগুলি সন্নিবেশ করানোর জন্য আপনাকে বিপরীতে এগুলি করতে হবে। (স্থানীয় সময় নিন এবং ডিবি স্টোরেজের জন্য ইউটিসিতে ফিরে রূপান্তর করুন) এটি সম্ভবত সবচেয়ে সাধারণ পন্থা। এটি "চাকা পুনরায় উদ্ভাবন" করার চেষ্টা থেকে আপনার অনেক সময় বাঁচাতে পারে। অজ্ঞাতনামা দর্শক যতদূর যায় ... আপনি এ) ইএসটি / ইডিটি (যথাযথ প্রদর্শনের জন্য অন্তর্নির্মিত ফাংশন কলগুলি ব্যবহার করে) বা খ) জিও-আইপি-লুকআপ জিনিসটিতে ফিরে যেতে এবং শিক্ষিত অনুমানের ভিত্তিতে একটি সময় অঞ্চল বেছে নিতে পারেন stick আপনি যে সময়-অঞ্চলটি তারিখ / সময়টি প্রদর্শন করছেন তা সর্বদা নির্দিষ্ট করাও একটি ভাল ধারণা ie অর্থ "12:00" কখনও বলবেন না ... এটি অবশ্যই "12:00 EDT" বলেছে তা নিশ্চিত করুন

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

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


8

এখানে সমস্যাটি রয়েছে: EU এবং মার্কিনরা একই সাথে ডিএসটি চালু এবং বন্ধ করে না; এই মার্চে, এই ইভেন্টগুলির মধ্যে তিন সপ্তাহের পার্থক্য ছিল।

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

Day (2001)   United States   Europe      United Kingdom   Global    Time delta
March 5th    EST 1500        CET  2100   GMT 2000         GMT 2000        +23h
March 6th    EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
March 7th    EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
..............................................................................
March 26th   EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
March 27th   EDT 1500        CEST 2100   BST 2000         GMT 1900        +24h

আসুন সমস্ত সম্ভাবনা বিশ্লেষণ করুন:

  • আপনি যদি বিশ্বব্যাপী টাইমজোনটিতে সময়টি প্রদর্শন করেন এবং এটিটিকে ইউটিসি বলে থাকেন , যা সঠিক কাজটি করার মতো মনে হয়, আপনি আপনার আমেরিকান গ্রাহকদের বিভ্রান্ত করতে যাচ্ছেন, যারা বিভিন্ন ইউটিসি সময় দেখতে পেয়ে যাচ্ছেন (গতকাল সন্ধ্যা 8 টা, আজ সন্ধ্যা 7 টা) একই প্রাচীর ঘড়ির সময় (গতকাল বিকাল ৩ টা, আজ আবার বিকেল ৩ টা) এবং তারপরে আপনার ইইউ ভিত্তিক গ্রাহকরা পোস্ট সময় ঘড়ির পরিবর্তন দেখতে পান না এবং এখনও তাদের প্রাচীর ঘড়ির ইভেন্টের সময়টি পরিবর্তন করতে হবে।

  • আপনি যদি বিশ্বব্যাপী টাইমজোনটিতে সময়টি প্রদর্শন করেন এবং এটিকে GMT কল করেন , মার্কিন গ্রাহকদের বিভ্রান্ত করার পাশাপাশি আপনি জিএমটি থেকে বিএসটিতে স্যুইচ করা যুক্তরাজ্যের গ্রাহকদেরও বিভ্রান্ত করবেন। EDT 1500 এবং EST 1400 একই সময়ে একই মুহূর্ত হয় তা বোঝার জন্য এটি বিপরীতমুখী ; এখন এটিকে বিএসটি / জিএমটিতে অনুবাদ করুন (অতিরিক্ত সমস্যার কারণে যে আপনি সাইটের কোনও অংশে বিএসটি বার দেখাবেন না)।

  • আপনি যদি কোন EU টাইমজোনটিতে টাইমজোনটি প্রদর্শন করেন ( GMT / UTC বিভ্রান্তি এড়াতে আমি সিইটি / সিইএসটি ব্যবহার করেছি ), এটি অবশ্যই আপনার মার্কিন গ্রাহকদের কাছে অত্যন্ত বিভ্রান্তিকর হতে চলেছে, যারা ইভেন্টের সময়টিকে দু'বার পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে পিছনে ঘেরাও দেখতে দেখতে পান এবং কোনও প্রাচীর না দেখে ঘড়ির সময় তাদের পরিবর্তন। আপনার মার্কিন গ্রাহকরা প্রথম স্যুইচে প্রস্তুত থাকতে পারে (সর্বোপরি তাদের একই দিনে তাদের প্রাচীরের ঘড়িগুলি পরিবর্তন করতে হবে), তারা পরবর্তীকালে অবাক হবেন।

  • আপনি যদি মার্কিন টাইমজোন ( EST / EDT এর মতো ) টাইমজোনটি প্রদর্শন করেন , আপনি উপরে সঠিক পরিস্থিতিটি ব্যাখ্যা করতে যাচ্ছেন, তবে মিরর!

এ যেন এক হতাশ অবস্থা বলে মনে হচ্ছে! এই অনড়বৃত্তির মধ্য দিয়ে যাওয়ার চার বছর পরে (বছরটিতে দুবার, স্পষ্টতই) আমি কীভাবে এটিকে সম্বোধন করতে এসেছি তা এখানে: "একটি টাইমজোন তৈরি করুন" "

আমি উপরের চিত্রের ঠিক একই অবস্থানে রয়েছি, তাই আমি "এনওয়াইটি" (নিউইয়র্ক টাইমজোন) তৈরি করেছি যাতে আমি "1500 এনওয়াইটি" লিখতে পারি যার অর্থ "টাইমজোন এটি যেই টাইমজোনটি ব্যবহার করে যা ঘটবে তাই বেলা তিনটায়" to

"Google এই সুবিধা হলো, এতক্ষণ ব্যবহারকারী জানেন যে ডিএসটি waltzer ঘটছে, তিনি তাদের নিজস্ব টাইমজোনে আপনাকে আগে পিছে রূপান্তর একটি খুব সহজ উপায় করেছে নিউ ইয়র্কের সময় " দেখতে কয়টা বাজে এনওয়াই হয় , তারপর সেখান থেকে এটি কাজ করে। এমনকি আপনি যেমন অভিনব এবং ব্যবহার ভূঅবস্থান-ভিত্তিক পরিষেবাগুলির পেতে পারেন time.is/15:00_in_New_York

মনে রাখবেন যে আপনি টাইমজোন সংক্ষিপ্তসার নাম সময় হিসাবে ব্যবহার করতে পারবেন , আমি আপনাকে অনুরোধ করছি না, কারণ তারা নিজেরাই এটি সম্পর্কে যথেষ্ট বিভ্রান্ত রয়েছে : EST এর EDT হিসাবে একই সময় রয়েছে‽

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


সব কিছু বলা হয়ে গেলে, আপনার বুঝতে হবে যে আমি ঘরে দীর্ঘকাল ধরে হাতিটিকে উপেক্ষা করে চলেছি এবং এটিই "কাউন্টডাউন" সমাধান যা আপনি ইতিমধ্যে বাস্তবায়ন করেছেন। "1 দিন 2 ঘন্টা 45 মিনিট 47 সেকেন্ডে" সম্পর্কে বিভ্রান্ত হওয়ার কিছু নেই (এবং যদি আপনি বিশ্বাস করেন যে আপনার এতটা নির্ভুলতার দরকার নেই যা আপনি আবার ভাবতে চাইতে পারেন )।

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


স্থানীয়করণ কি আসলেই ভাল বিকল্প নয়? আমি মনে করি যে এটি সবচেয়ে ভাল উপায়, যদি এটি সর্বদা সঠিক থাকে।
জেটি 703

@ jt703 আমি ভেবেছিলাম স্থানীয়করণ (time লা টাইম.আইএস) কোনও কারণে আপনার কাছে অনুপলব্ধ, কারণ যতক্ষণ এটি কাজ করে ততক্ষণ এটি দেখতে বেশ ভাল সমাধান বলে মনে হয়। তবুও, ডিএসটি আপনার ব্যবহারকারীদের অপ্রস্তুত করে ফেলতে পারে। :)
Badp
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.