تظهر إدخالات التاريخ الجديدة في موضوع ما بهذا الشكل في رسائل الإعلامات المقابلة:
2024-04-18T16:00:00Z UTC→2024-04-18T20:00:00Z UTC
بالنسبة لقناة نشر البريد، يجب إعادة تنسيق هذا إلى معلومات تاريخ قابلة للقراءة البشرية مع مراعاة المنطقة الزمنية الحالية (في هذه الحالة: CET) لمثيل Discourse.
لا تمتلك مثيلات ديسكورس “منطقة زمنية”. تمتلك جلسات المستخدم الفردية.
حسنًا، في هذه الحالة، يجب تحويل سطر التاريخ إلى المنطقة الزمنية للمستخدم الذي يتلقى البريد الإلكتروني للإشعار.
لا 
بالنسبة للمستخدم المتلقي، يجب ترجمتها إلى منطقته الزمنية الخاصة. لذا، بدلاً من
UTC 2024-04-18، 16:00-20:00 يجب أن تُقرأ
CET 2024-04-18، 18:00-22:00
في التقويم المرئي في أعلى الموضوع لدي أيضًا الوقت الصحيح
لا أعتقد أن هذا طلب معقول، لأنه سيتطلب بحثًا فرديًا إضافيًا ومعالجة من جانب الخادم لكل بريد إلكتروني
لا أعرف الكود هنا، ولكن هذا عيب محتمل، وأنا أوافق.
من ناحية أخرى، نرى التاريخ الصحيح في التقويم المرئي في الأعلى … يجب على شخص يعرف الكود أن يعلق على هذا …
لم أفحص الكود ولكني أفترض أنه على الويب، يتم تحميل التاريخ بنفس الطريقة من قاعدة البيانات إلى العميل ويتم تحليله من جانب العميل عبر جافاسكريبت (وهو خيار غير متاح لك عند عرض المحتوى من جانب العميل في عميل البريد الإلكتروني)
بالتأكيد، بمجرد مغادرة البريد الإلكتروني لخوادمنا، لا توجد لدينا طريقة للتكيف مع المنطقة الزمنية للمستلم
كان هناك بعض المناقشات السابقة حول هذا الموضوع: Discourse local dates need better presentation in emails
كان التبديل إلى التوقيت العالمي المنسق (UTC) تحسينًا مقارنة بعدم عرض أي منطقة زمنية، أو وضع مطول جدًا حيث قد نعرض 3 مناطق زمنية لكل تاريخ… ولكن لم يكن هناك متابعة لاستخدام المنطقة الزمنية للموقع/المستخدم.
حتى لو كانت على بعد بضع مناطق زمنية، يمكن للكثير من الأشخاص على الأرجح تخمين أفضل عند البدء من منطقة زمنية محددة بدلاً من التوقيت العالمي المنسق (UTC).
إن التوقيت العالمي المنسق الحالي في رسائل البريد الإلكتروني سيء للغاية بالنسبة لـ “المستخدم العادي”، خاصة إذا كنت على الجانب الآخر من العالم (مثل نيوزيلندا).
تعتمد العديد من المنتديات التي تستخدم Discourse على منطقة زمنية واحدة؛ بالنسبة لهذه المنتديات، سيكون من الرائع أن تكون قادرًا على تحديد المنطقة الزمنية الافتراضية المعروضة في رسائل البريد الإلكتروني الخاصة بها.
بالنسبة لتلك التي تمتد عبر المناطق الزمنية، نعم، الأمر أكثر تعقيدًا - ويتضح ذلك من سبب وجود حل “مؤقت” عمره 5 سنوات. أود أن يعمل شخص أذكى بكثير (أو على الأقل أكثر تفانيًا) مني على حل هذه المشكلة.
[اقتباس=“nathank, post:10, topic:299937”]
التوقيت العالمي المنسق (UTC) الحالي في رسائل البريد الإلكتروني سيئ حقًا حقًا بالنسبة ‘للمستخدم العادي’، خاصةً إذا كنت في الجانب الآخر من العالم (مثل نيوزيلندا).
تتمركز العديد من المنتديات التي تستخدم ديسكورس في منطقة زمنية واحدة؛ بالنسبة لأولئك، سيكون من الرائع أن تكون قادرًا على تحديد المنطقة الزمنية الافتراضية المعروضة في رسائل البريد الإلكتروني لهم.
[/اقتباس]
أوافق تمامًا بنسبة 100٪. لدينا منتدى يقع في أستراليا ويستخدم مواضيع مغلقة كقوائم بريدية بحكم الواقع. يقع الجميع تقريبًا في أستراليا ويتوقعون أن تعكس أوقات الاجتماعات ذلك. التوقيت العالمي المنسق (UTC) في رسائل البريد الإلكتروني مربك تمامًا للعديد من المستخدمين.
ألا يمكننا على الأقل تعيين المنطقة الزمنية المستخدمة والسماح لكل نسخة باختيار تجاوزها أم لا.
@j.jaffeux / @hugh / @lindsey ما رأيكم في:
إنه:
discourse_local_dates_email_timezone الذي يسمح بتكوينلذلك في حالات discourse المحلي للغاية، ستقوم بتعيينه إلى المنطقة الزمنية للبلد، مما يجعل رسائل البريد الإلكتروني أقل إرباكًا.
هذا للأسف أكثر تعقيدًا بعض الشيء، ولا يمكن ملاءمة ذلك في خط الأنابيب بسهولة.
مهما كانت طريقة عرض الوقت، يرجى الرجاء الرجاء دائمًا تضمين المنطقة الزمنية المختارة!
عذرًا، أنا لا أفهم، هل يمكنك التوسع في ما تعنيه هنا؟
[اقتباس=“sam, post:12, topic:299937”]
تغيير تنسيق البريد الإلكتروني الافتراضي إلى llll (على سبيل المثال: الثلاثاء، 8 مايو 2018 2:00 صباحًا)
من 2018-05-08T00:00:00Z UTC
[/اقتباس]
في النص المثال، لا يوجد منطقة زمنية. أقول أن هذا سيكون سيئًا، إذا كان هذا هو ما سيتم استخدامه حرفيًا. أقترح بشدة إضافة واصف المنطقة الزمنية المناسب المكون من ثلاثة أو أربعة أحرف، أو واصف البلد/المدينة المطول. يحتوي النص الحالي على “UTC” وهو مؤشر لا لبس فيه لما هو المقصود - يجب أن يكون السلوك الجديد جيدًا على الأقل مثل ذلك.
حتى في “الخطاب المحلي للغاية”، قد يكون هناك مستخدمون في مناطق زمنية مجاورة، وقد تكون هناك تحولات التوقيت الصيفي، وقد يكون هناك مستخدمون مسافرون ويصلون من بعيد.
من نفس علاقة العمل 
discourse_local_dates_email_format:
default: "llll UTC"
ليس تلة سأموت عليها، ولكن من الصعب جدًا فهم التواريخ الآن، لذلك أنا أسعد بأن تحصل مدن نيويورك/لندن/باريس على شيء أقل إرباكًا قليلاً… ولكن من الصعب جدًا التوصل إلى تنسيق يفوز للجميع.
يمكننا الاحتفاظ بالوضع الراهن الافتراضي على الرغم من ذلك
[اقتباس=“sam, post:16, topic:299937”]
discourse_local_dates_email_format:
default: "llll UTC"
[/اقتباس]
ماذا سيحدث إذا قمت بتغيير discourse_local_dates_email_timezone إلى “Europe/Paris” ولكنني لم أقم بتحديث التنسيق إلى “llll Europe/Paris”؟ هل سيؤدي ذلك إلى تحويل الوقت إلى توقيت باريس ولكن سيظل يعرض “UTC” بعده؟
[اقتباس=“Moin، المشاركة: 17، الموضوع: 299937”]
هل سيتسبب ذلك في تحويل الوقت إلى توقيت باريس ولكنه سيظل يعرض “UTC” بعده؟
[/اقتباس]
نعم، هذا ما سيحدث، الإعدادات متشابكة، يجب عليك تغيير كليهما.
قبل طلب السحب الخاص بي، قمنا بتضمين النص “UTC” بشكل ثابت، لذلك لم يكن هذا قابلاً للتكوين حتى.
يبدو ذلك عرضة للخطأ بالنسبة لي. هل من الممكن إظهار المنطقة الزمنية المحددة تلقائيًا بدلاً من توقع قيام المسؤول بتحديث التنسيق يدويًا؟ هل سيؤدي استخدام "llll z" كإعداد افتراضي لـ discourse_local_dates_email_format إلى العمل؟
صيد رائع يا موين 
لقد نجح، لقد قمت بتحديث طلب السحب الخاص بي