تاریخ شمسی در ووکامرس: چرا دردسر دارد و چطور حلش کنیم
هیچ افزونهای تاریخها را در پایگاهداده شمسی نمیکند. یک لایه ترجمه روی سطح است، و لبههایش جاهایی باز میمانند که کسی نگاه نمیکند.
فهرست مطالب
- هیچ افزونهای تاریخ را در پایگاهداده شمسی نمیکند؛ وردپرس میلادی و بر مبنای زمان جهانی ذخیره میکند.
- این معماری درست است — تاریخ یکجور ذخیره میشود و چندجور نمایش داده میشود.
- خروجی اکسل، گزارشهای تحلیلی و رابط برنامهنویسی معمولا میلادی میمانند.
- خروجی استاندارد رابط برنامهنویسی باید میلادی بماند، وگرنه اتصالهای بیرونی میشکنند.
- سفارش ساعت یازده و نیم شب ممکن است با تاریخ روز بعد ذخیره شود — منشا اختلاف گزارش ماه.
- اگر قالب هم تبدیل تاریخ داخلی داشته باشد، یک تاریخ دو بار ترجمه میشود.
- تاریخی که در فاکتور به متن تبدیل شده دیگر با تغییر تنظیمات اصلاح نمیشود.
اولین باری که فروشنده ایرانی پنل ووکامرس را باز میکند و میبیند تاریخ سفارش 2026-09-02 است، فکر میکند یک تنظیم جا افتاده. میگردد دنبال گزینهای که تاریخ را شمسی کند، پیدا نمیکند، افزونه نصب میکند، درست میشود، و خیال میکند مسئله حل شد.
مسئله حل نشده. فقط جای دیگری رفته — و آن جای دیگر معمولا گزارش مالی آخر ماه است.
افزونه تاریخ شمسی واقعا چه کار میکند
این را باید روشن گفت: هیچ افزونهای تاریخها را در پایگاهداده شمسی نمیکند. وردپرس تاریخ را به شکل میلادی و بر مبنای زمان جهانی ذخیره میکند و این تغییرپذیر نیست.
کاری که افزونه میکند این است: در لحظه نمایش، عدد میلادی را میگیرد و شمسی نشانش میدهد. یک لایه ترجمه روی سطح، نه تغییر در عمق.
این معماری در واقع درست است. تاریخ باید یکجور ذخیره شود و چندجور نمایش داده شود. مشکل جای دیگری است: این ترجمه فقط جاهایی اتفاق میافتد که افزونه به آنها رسیده باشد.
کجاها ترجمه نمیشوند
| جا | معمولا شمسی میشود؟ |
|---|---|
| فهرست سفارشها در پنل | بله |
| تاریخ نوشته و محصول | بله |
| خروجی اکسل سفارشها | معمولا نه |
| ایمیلهای ووکامرس | گاهی نه |
| گزارشهای تحلیلی ووکامرس | اغلب نه |
| خروجی رابط برنامهنویسی | نه، و نباید هم بشود |
ردیف آخر عمدی است و درست: هر سیستمی که از بیرون به سایتت وصل میشود — اپ، پل حسابداری، سرویس ارسال — باید تاریخ استاندارد بگیرد. اگر افزونهای این را هم شمسی کند، آن اتصالها میشکنند.
ولی ردیف سوم و پنجم دردسر واقعیاند. تو در پنل تاریخ شمسی میبینی و در خروجی اکسل میلادی، و بعد باید در ذهنت تبدیل کنی. مالیات فروشگاه اینترنتی نشان میدهد چرا همین تبدیل ذهنی سر گزارش ماهانه دردسر میشود.
تله اصلی: مرز روز
این جدیترین بخش این نوشته است. روز شمسی و روز میلادی از یک لحظه شروع نمیشوند، و ذخیرهسازی هم بر مبنای زمان جهانی است نه ساعت تهران.
یعنی سفارشی که در تهران ساعت یازده و نیم شب ثبت شده، در پایگاهداده ممکن است با تاریخ روز بعد ذخیره شده باشد. اگر منطقه زمانی وردپرس درست تنظیم نشده باشد، این پنجره بزرگتر هم میشود.
نتیجهاش اینطور خودش را نشان میدهد: گزارش فروش ماه در پنل با گزارش حسابداری چند سفارش فرق دارد و هیچکس نمیفهمد چرا، چون هر دو طرف «درست» کار کردهاند. اولین کاری که باید بکنی این است که در تنظیمات وردپرس منطقه زمانی را روی تهران بگذاری، نه روی اختلاف عددی.
تله دوم: دو افزونه که هر دو ترجمه میکنند
خیلی از قالبهای فارسی و افزونههای فاکتور، خودشان یک تبدیل تاریخ داخلی دارند. اگر تو هم افزونه تاریخ شمسی نصب کنی، ممکن است یک تاریخ دو بار تبدیل شود.
نتیجهاش تاریخهای عجیبی است که نه شمسیاند نه میلادی، و معمولا فقط در یک صفحه خاص دیده میشوند — مثلا فقط در فاکتور چاپی. پیدا کردنش سخت است چون بقیه سایت درست است.
این یکی از آن تعارضهایی است که هیچ خطایی تولید نمیکند و فقط با نگاه کردن پیدا میشود. افزونه ووکامرس درباره همین دسته از برهمکنشها میگوید.
تله سوم: تاریخی که به متن تبدیل شده
بعضی افزونهها هنگام ساخت فاکتور، تاریخ را بهشکل متن داخل سند ذخیره میکنند. از آن لحظه، آن تاریخ دیگر تاریخ نیست، یک رشته حروف است.
یعنی اگر بعدا افزونه تاریخ شمسی را عوض کنی یا منطقه زمانی را اصلاح کنی، آن سندهای قدیمی اصلاح نمیشوند. برای اسناد مالی این در واقع رفتار درستی است — فاکتور نباید بعدا عوض شود — ولی باید بدانی که هست، وگرنه دنبال باگی میگردی که وجود ندارد.
تقویم انتخاب تاریخ، و چیزی که پاک نمیشود
هر جای ووکامرس که تاریخ وارد میکنی — انقضای کد تخفیف، زمانبندی انتشار محصول، بازه گزارش — یک تقویم دارد. افزونههای شمسی این تقویمها را هم عوض میکنند، ولی نه همهشان را.
و یک رفتار آزاردهنده که در بعضیشان هست: وقتی تاریخی را وارد کردی، راهی برای خالی کردنش نداری. مثلا کد تخفیفی که یک بار تاریخ انقضا گرفته، دیگر نمیتواند بیانقضا شود مگر با پاک کردن و ساختن دوبارهاش. قبل از ثبت انبوه کد تخفیف، این را یک بار تست کن.
چکلیست
- منطقه زمانی وردپرس را روی تهران بگذار، نه روی اختلاف عددی
- فقط یک افزونه تاریخ شمسی داشته باش، و قالب را هم چک کن
- یک خروجی اکسل بگیر و ببین تاریخش شمسی است یا میلادی
- یک سفارش آزمایشی بعد از ساعت یازده شب ثبت کن و تاریخش را در هر دو جا ببین
- یک فاکتور قدیمی را باز کن و ببین تاریخش با تغییر تنظیمات عوض میشود یا نه
جمعبندی
تاریخ شمسی در ووکامرس یک وصله نمایشی است، نه یک قابلیت. و چون وصله است، لبههایش جاهایی که کسی نگاه نمیکند باز میمانند: خروجی اکسل، گزارش تحلیلی، فاکتور چاپی.
مهمترین کاری که امروز میتوانی بکنی این است که منطقه زمانی را چک کنی و یک سفارش شبانه آزمایشی بدهی. اگر تاریخ آن سفارش در دو جای مختلف دو روز متفاوت بود، همین حالا منشا اختلاف گزارشهای آیندهات را پیدا کردهای.
سؤالهای پرتکرار
چرا ووکامرس تاریخ شمسی ندارد؟
چون وردپرس تاریخ را به شکل میلادی و بر مبنای زمان جهانی ذخیره میکند و این تغییرپذیر نیست. افزونههای تاریخ شمسی هم پایگاهداده را عوض نمیکنند؛ در لحظه نمایش عدد میلادی را میگیرند و شمسی نشان میدهند. این معماری در واقع درست است، ولی یعنی ترجمه فقط جاهایی اتفاق میافتد که افزونه به آنها رسیده باشد.
چرا خروجی اکسل سفارشها میلادی است؟
چون افزونه تاریخ شمسی لایه نمایش پنل را عوض میکند، نه دادهای که برای خروجی خوانده میشود. همین برای گزارشهای تحلیلی ووکامرس و ایمیلها هم اغلب صادق است. نتیجهاش این است که در پنل شمسی میبینی و در خروجی میلادی، و تبدیل در ذهن تو انجام میشود.
چرا گزارش فروش ماه با حسابداری چند سفارش اختلاف دارد؟
به احتمال زیاد بهخاطر مرز روز. روز شمسی و روز میلادی از یک لحظه شروع نمیشوند و ذخیرهسازی بر مبنای زمان جهانی است، پس سفارشی که در تهران ساعت یازده و نیم شب ثبت شده ممکن است با تاریخ روز بعد ذخیره شده باشد. اگر منطقه زمانی وردپرس هم درست تنظیم نشده باشد، این پنجره بزرگتر میشود.
چرا تاریخ در فاکتور چاپی عجیب است؟
دو حالت رایج دارد. یکی اینکه قالب یا افزونه فاکتور خودش تبدیل تاریخ داخلی دارد و تاریخ دو بار ترجمه شده. دیگری اینکه افزونه تاریخ را هنگام ساخت فاکتور به شکل متن ذخیره کرده، پس آن سند دیگر با تغییر تنظیمات اصلاح نمیشود. برای اسناد مالی حالت دوم در واقع رفتار درستی است.
میشود تاریخ انقضای کد تخفیف را خالی کرد؟
در بعضی افزونههای تقویم شمسی نه. وقتی تاریخی وارد شد، راهی برای خالی کردنش نمیگذارند و تنها راه، پاک کردن و ساختن دوباره کد تخفیف است. قبل از ثبت انبوه کد تخفیف، یک نمونه بساز و همین را تست کن.
اول چه کاری باید بکنم؟
منطقه زمانی وردپرس را روی تهران بگذار، نه روی اختلاف عددی. بعد یک سفارش آزمایشی بعد از ساعت یازده شب ثبت کن و تاریخش را هم در پنل و هم در خروجی اکسل ببین. اگر دو روز متفاوت نشان داد، منشا اختلاف گزارشهای آیندهات را همین حالا پیدا کردهای.
فروشگاهی که این راهنما دربارهاش است، همینجا ساخته میشود.
محصول و قیمت و صفحه قوانین و یک فرایند خرید سالم — همان چیزهایی که کارشناسها دنبالشان میگردند — از روز اول سر جایشان هستند.
