تاریخ سال میزبانی دروپال وسیعی
ارسال شده توسط arlinsandbulte در تاریخ 30 مارس، 2012 در 13:46
من می دانم این است که رفتن به یک موضوع بحث برانگیز است. بنابراین من می خواهم به سر کردن نبرد و شروع به بحث خودم حق دور.
KARENS پیشنهاد کرده است اتخاذ فرمت ISO به عنوان تنها فرمت پشتیبانی برای نسخه های آینده از ماژول تاریخ (به contrib را 7.x و-های 3.x هسته 8.X!). من 100٪ به نفع این پیشنهاد است.
این ساده پشتیبانی توسعه سازگاری چند پلت فرم. از بسیاری از استانداردهای فرمت تاریخ (یونیکس برچسب زمان، تاریخ ساعت، و غیره)، آن را بیشتر انعطاف پذیری به عنوان بخشهایی از تاریخ فراهم می کند زمان را می توان حذف برای کنترل دانه دانه ابهام.
توابع تاریخ جدید پی اچ پی کار با تاریخ های از هر فرمت راحت تر از همیشه قبل از. بنابراین، من فکر نمی کنم فرمت های سنتی زمان یونیکس دارای یک سهولت استفاده، استفاده مانند آن یک بار انجام داد.
با این حال، ما نیز باید اشکالاتی اذعان محدودیت های این پیشنهاد (گذاشتن کلاه روی وکیل مدافع شیطان من):
- قالب تاریخ ISO است بومی توسط تمام پایگاه های داده (مانند MySQL) پشتیبانی نمی شود. بنابراین، ما در ذخیره سازی ارزش تاریخ ISO به عنوان یک رشته varchar و در پایگاه داده برنامه ریزی کنید. تاریخ نمایش داده شد می توان با استفاده نمایش داده شد زیر رشته را پیدا تاریخ خاص ساخته شده (به عنوان مثال، تمام تاریخ با سال 2012). عملکرد، من فکر نمی کنم سه فاز هر گونه مشکل با آن است. البته این امکان نیز اجرای این طرح، در حالی که هم فقط در مورد هر نوع پایگاه داده با هک خاص حداقل یا بدون پایگاه داده و یا کار arounds حمایت. اما، چه در مورد عملکرد؟ چه مقدار از عملکرد ضربه است اجرای سوالات زیر رشته در برابر «واقعی» مادری پایگاه داده ارزش وجود داشته است؟
- هسته دروپال (<=7.x) uses the unix timestamp format to store date & time information, most notably, for content created/updated dates. Going along with the current trend of making all content parts fields (body, terms, even titles), it might be desirable to make the created or updated date a real 'date field' too. What are the implications of this? Would all Drupal dates (like node created/updated dates) be converted to the ISO format? Or would we keep 2 different date types mixed into core?
این قبل از زمان من بود، اما من فکر می کنم نسخه های اولیه از تاریخ در واقع هر بخش از تاریخ (سال، ماه، روز، ساعت، دقیقه، ثانیه) در ستون پایگاه داده جداگانه ذخیره می شود. این استراتژی اجازه می دهد تا فرمت ذخیره سازی عدد صحیح است.
اما من به شدت شک دارم که استراتژی ارزش آن است. و مگر اینکه خلاف آن ثابت شود، من آن حمایت می کنند.
/ من (-) رای پست :-) من
من واقعا از دست رفته استدلال فنی روشن در اینجا.
فرمت نحو تاریخ ISO، که در اینجا ارائه شده، در درجه اول را حس می کند به خاطر نمایش و ارتباط با اطلاعات روز در احزاب غیر این صورت مستقل (به عنوان مثال بین باطن (پی اچ پی) و ظاهر (جاوا اسکریپت)).
این واقعا مناسب به عنوان یک نحو و / یا نوع داده برای ذخیره سازی و پرس و جو داده های تاریخ، به دلیل نحو بسیار انعطاف پذیر است (و در نتیجه واقعا یک نوع داده، به غیر از "متن").
- چه تفاوت واقعی بین تاریخ / DateTime و فرمت تاریخ استاندارد ISO است؟
جدا از "T"؟ en.wikipedia.org/wiki/Iso_date_format توصیف بسیاری دیگر جداکننده در نحو ISO، اما تا حدی شکی نیست که ما در حال رفتن به اجازه هر گونه استفاده از آنها - به خاطر اینکه قادر به پرس و جو داده در یک پیش بینی / راه سازگار؟
به عنوان مثال. اگر ما اجازه می دهد به نحو جایگزین تاریخ هفته (2012-W13-5) و یا نحو تاریخ ترتیبی به نظر می رسد در تقویم / تاریخ / زمان نحو، سوابق را نمی توان بر اساس تاریخ فیلتر دیگر، از آنجا که شما نیاز به انجام محاسبات تاریخ پیشرفته به تساوی داده است.
(همین امر به حذف اجزای دانه های ریز تر از تاریخ / زمان، از هر گونه فیلتر مبتنی بر رشته / مرتب سازی عملیات بر روی قطعات از دست رفته را شکست.)
است که چون موتور پایگاه داده می توانید هر شاخص و یا توابع بومی برای بهینه سازی پرس و جو استفاده کنید. معنی یک تأثیر عملکرد از ثانیه (نه میلی ثانیه) برای پرس و جو پایگاه داده واحد در سراسر یک مجموعه داده بزرگ است.
استاندارد SQL ISO 8601 به عنوان فرمت پیش فرض، که تقریبا همان تعریف می کند.
(بله، از SQLite تنها پشتیبانی از یک رشته متن، اما از SQLite می کند بسیاری از انواع داده را پشتیبانی نمی کند در هر صورت، بنابراین احتمالات خیلی در آن موتور محدود به هر حال.)
نوع داده مناسب اجازه می دهد تا برای فیلتر بومی و مرتب سازی از ارزش ها، که می تواند نمایه میشود. سیستم های انتقال مواد به SQL Query عنوان ساده به عنوان برخورد با برچسب زمانی Unix است.
شخصی (دانه های ریز تر) قطعات تاریخ نمی تواند حذف شود، اما به خاطر ذخیره سازی داده ها مختصر و درست است، خواص مانند "allday" و مشابه باید به طور جداگانه پرچم در تاریخ راه های ذخیره شده (و مورد استفاده شده خاص به عنوان آنها نمی اعمال می شود به تمام تاریخ در وهله اول، به عنوان مثال برای محتوای ایجاد شده و تاریخ اصلاح شده).
من نمی خواهد ذهن با استفاده از یک میدان حسگر ناحیه رنگی مادری اگر ما می تواند آن را دوباره به هسته است. اما من در حال حاضر سعی مبارزه که مبارزه و از دست داد. و من قصد دارم برای ایجاد یک راه حل که با استفاده از یک میدان حسگر ناحیه رنگی مادری هنگامی که آن را ساخته شده است کاملا روشن است که اعمال کننده هسته را به یک میدان حسگر ناحیه رنگی در هسته اجازه نمی دهد.
ارسال شده توسط arlinsandbulte در آوریل 10، 2012 در 04:41
من شک دارم که ما نیاز به محدود کردن فرمت ISO ذخیره شده به YYYY-MM-DDTHH: فرم SS به حفظ انسجام و آسان به جستجو و انواع: MM.
: MM: شاید حتی ± Y YYYY-MM-DDTHH استفاده از فرمت SS برای طیف وسیع تری از تاریخی اجازه می دهد تاریخ آینده است که یک درخواست مشترک در date.module بوده است. اما، دست زدن به تاریخ در PHP وجود دارد ممکن است یک محدودیت به هر حال.
همچنین، حتی اگر این استاندارد ISO اجازه می دهد تا حذف بخش های کمتر قابل توجهی به کاهش دقت، انجام این کار ممکن انواع و جستجو را سخت تر کند. به همین دلیل، ما هنوز هم ممکن است لازم باشد برای ذخیره "چیزی" برای هر بخش است. (لطفا با من اگر از من اشتباه می کنم. من یک کارشناس پایگاه داده نمی شود).
-ایده های وحشی: ما می تواند '99' ذخیره در هر بخشی تاریخ سازمان ملل متحد مورد نیاز است. که کار می کند برای تمام قطعات به جز سال، بلکه باعث می شود ذخیره می شود تاریخ رشته غیر ISO سازگار است.
ارسال شده توسط دیوید اشتراوس در آوریل 9، 2012 در 19:57
راه ISO 8601 دسته ساعت در مناطق بسیار مرگ مغزی است. منطقه زمان یک کاربر / محتوای نگرانی مورد محلی سازی، نه چیزی است که باید از پیش تنظیم شده در تاریخ ذخیره شده با حاشیه نویسی در مورد نحوه نمایش تاریخ از ساعت محلی UTC تنظیم متفاوت است. این باعث می شود داده های سخت به خواندن و می شکند رشته مرتب سازی (که در غیر این صورت با تاریخ ISO جامد).
من فقط می توانم این پیشنهاد حمایت اگر ما به استفاده از زمان UTC / زولو در پایگاه داده می چسبد. نکته اصلی من در مورد تاریخ ما استفاده از یونیکس برچسب عصر دوست داشتم این است که بدانیم که آنها همیشه در UTC هستند.
ارسال شده توسط KARENS در آوریل 11، 2012 در 11:19
بله، سوال در مورد زمانی که / آیا برای تبدیل بار به ساعت محلی UTC تنظیم برای ذخیره سازی یک سوال جداگانه است و ما نیاز به یک بحث جداگانه در مورد آن. اگر چه ISO دارای گزینه ای برای اضافه کردن اطلاعات منطقه زمانی به رشته، من در واقع پیشنهاد نمی کنم که ما انجام این کار، من فقط اشاره می کرد که ممکن است. من برنامه ریزی برای باز کردن یک مسئله جداگانه در مورد آن موضوع (یا هر کس دیگری می تواند).
استاندارد ISO دارای زیادی برای رفتن آن، بسیاری از مردم در حال حاضر از طریق چیزهایی که باید در تاریخ نشان داده می شود و یک فرمت جهانی قابل درک برای آن ایجاد شد. زمینه های پایگاه داده حسگر ناحیه رنگی مادری در واقع آن را استفاده بیش از حد.
من نمی خواهم برای اضافه کردن + - پیشوند به آن بنابراین ما می توانیم تاریخ قبل از میلاد، پشتیبانی و است که ما همه چیز بسیار زیبا است که در طول سال درخواست شده است به من بدهید. تبدیل از / به این فرمت از فرمت های دیگر را می توان با پی اچ پی گرفته شده است. و تبدیل منطقه زمانی را می توان با پی اچ پی گرفته شده است.
موضوع باقی مانده که ممکن است به یک نگرانی عملکرد رشته مقابل INT (برچسب زمان) و زمینه های حسگر ناحیه رنگی بومی است، بنابراین من یک بحث جداگانه در مورد آغاز شده است که به شکل از آنچه هزینه واقعی است و آنچه ما می توانند انجام دهند عملکرد به خوبی تا جایی که ممکن است. اما هنگامی که با توجه به قابلیت حمل پایگاه داده، ISO در یک میدان varchar و یک برنده بزرگ است.
ارسال شده توسط arlinsandbulte در آوریل 11، 2012 در 01:52
خواهد با اضافه کردن + - مطرح یک مشکل برای مرتب سازی؟
بدون + -، مرتب سازی صعودی رشته YYYY-MM-DD به طور طبیعی در جهت سمت راست نتایج: از شماره (اولین تاریخ اول آخرین تاریخ گذشته).
اما، با اضافه کردن + - تغییر داده است. مرتب کردن بر اساس نتایج رشته صعودی ساده در تمام تاریخ + برای اولین بار، طبقه بندی شده اند با اولین تاریخ را به آخرین تاریخ و به دنبال آن همه - خرما، طبقه بندی شده اند با آخرین تاریخ به اولین تاریخ.
به عنوان مثال، در اینجا یک لیست مرتب شده از رشته ها تنها در سال است:
"0000"
"1800"
"1900"
"1977"
"2000"
"2012"
"-0100"
"-0500"
"-1000"
"-5000"
ارسال شده توسط آلن D. در 27 سپتامبر 2012 در 01:50
به نظر می رسد دیوانه به عقب و این زمینه DB پشتیبانی نمی کند. به استثنای همه از چیزهای افزودنی در تاریخ، آن را به یک ماژول عظیم است و در تمام سیستم های دیگر من در کار می کرد، طبقات تاریخ پشتیبانی کلاس و بی اهمیت از 1000 یا خط کد هستند.
پس این است که واقعا یک سوال اشاره کارگردانی به DB نویسان راننده، می تواند یک میدان کسر ثانیه تاریخ و داخلی تبدیل می شود به حمایت از یک میدان شبه تاریخ ساعت؟
تقسیم کردن ستون به اجزای منفرد کار می کند، اما بسیار کثیف است (که من در تاریخ جزئی انجام داده اند)، و واقعا نمی توصیه پایین رفتن در این مسیر. من احساس می کنم خودم را در پای وی شلیک انجام این کار خواهد شد و در بازگشت این در نسخه های آینده است.
بدون بازخوانی مشخصات ISO دوباره (یا در حال اجرا آزمون)، علامت مثبت اختیاری است اگر من به خاطر حق، به طوری که علامت منفی مورد نیاز است که نفی مسائل مرتب سازی اگر من خواندن جداول ASCII به درستی. (- 45، و 0 تا 9 وسیعی 48 تا 57). با استفاده از + (ASCII 43) مرتب کردن بر اساس شکند اینجا.
پشتیبانی از منطقه زمانی (و یا عدم)
من قبول دارم که تنها با استفاده از یک منطقه زمانی تنها در پایگاه داده است (UTC) به عنوان آن را نفی برخی از منفی در سفارش و جستجو داده ها هنگامی که زمینه های تاریخ DB بومی حمایت نخواهیم کرد.
یک دو حلقه به همه آنها را رد؟
من با خورشید توافق برسند، ما باید این را به بسیار ساده زیر مجموعه ای از فرمت های گسترده پشتیبانی محدود می کند. شاید تنها
در حالی که در حال حاضر با ماژول تاریخ را پشتیبانی نمی شود، اطلاعات منطقه زمانی ندارد به این معنی بر روی تاریخ، 2012/01/01 در امریکا نزدیک به یک روز تمام پشت 2012/01/01 در استرالیا است. بنابراین شاید پشتیبانی از زمینه را می توان به یک میدان-ISO مانند و یک میدان-ISO مانند با پشتیبانی منطقه زمانی کاهش می یابد؟ این قطره پشتیبانی از زمان، اما من فکر نمی کنم که هسته باید زمینه های زمان حمایت می کنند.
در نهایت، دروپال یخ 8 ویژگی: 2012 دسامبر 1