تاریخ شمسی در فرم آنلاین: سه اشتباهی که داده را خراب می‌کند

تقویم شمسی فقط یک نمایش متفاوت نیست. اگر تبدیل را جای اشتباهی انجام دهید، گزارش‌هایتان یک روز جابه‌جا می‌شود.

تیم پرسینو۲۵ شهریور ۱۴۰۵۲ دقیقه خواندن

هر فرم فارسی بالاخره به تاریخ می‌رسد: تاریخ تولد، تاریخ شروع کار، تاریخ رویداد. سه اشتباه هست که تقریباً همه یک بار مرتکبش می‌شوند.

اشتباه اول: ذخیره‌ی تاریخ به صورت متن شمسی

وسوسه‌انگیز است که «۱۴۰۴/۰۶/۲۱» را همان‌طور که هست ذخیره کنید. مشکل وقتی پیدا می‌شود که بخواهید مرتب کنید یا بازه بگیرید. مرتب‌سازی متنی «۱۴۰۴/۱۰/۰۱» را قبل از «۱۴۰۴/۰۹/۳۰» می‌گذارد، چون «۱۰» الفبایی کوچک‌تر از «۰۹» نیست ولی «۱» کوچک‌تر از «۰» هم نیست — و نتیجه آشفتگی است.

راه درست: تاریخ همیشه به صورت میلادی/ISO ذخیره شود و فقط موقع نمایش شمسی شود. کاربر شمسی می‌بیند، پایگاه‌داده میلادی می‌فهمد، و مرتب‌سازی و بازه‌گیری درست کار می‌کند.

اشتباه دوم: منطقه‌ی زمانی

اگر تاریخ را در مرورگر کاربر به میلادی تبدیل کنید و مرورگر روی UTC باشد، «۱۴۰۴/۰۶/۲۱» ممکن است بشود «۲۰۲۵-۰۹-۱۱T۲۰:۳۰Z» که در ایران هنوز همان روز است ولی در UTC روز قبل. بعد گزارش «امروز» یک روز عقب می‌افتد.

قاعده: تاریخِ بدون ساعت (تاریخ تولد، تاریخ قرارداد) باید بدون منطقه‌ی زمانی و به‌عنوان یک روز تقویمی ذخیره شود، نه به‌عنوان یک لحظه. لحظه‌ها (زمان ثبت پاسخ) با منطقه‌ی زمانی ذخیره می‌شوند.

اشتباه سوم: سال کبیسه

تقویم شمسی الگوی کبیسه‌ی متفاوتی از میلادی دارد. ۳۰ اسفند فقط در سال‌های کبیسه وجود دارد. اگر اعتبارسنجی تاریخ را خودتان با «روز بین ۱ و ۳۱» بنویسید، هم ۳۱ اسفند را می‌پذیرید (که هیچ‌وقت وجود ندارد) و هم ممکن است ۳۰ اسفندِ یک سال کبیسه را رد کنید.

این را خودتان ننویسید. کتابخانه‌ی آزموده استفاده کنید.

نکته‌ی کوچکی که تجربه را بهتر می‌کند

برای تاریخ تولد، انتخابگر تقویمی بد است: کاربر باید ۳۰ سال به عقب کلیک کند. برای تاریخ تولد، سه فهرست (روز/ماه/سال) یا ورودی مستقیم بهتر است. تقویم برای تاریخ‌های نزدیک — رزرو نوبت، تاریخ جلسه — مناسب است.

برچسب‌ها:تاریخ شمسیجلالیداده تمیز