در مورد تغییر رفتار ساعت در ایران که امسال اعمال شده و مشکلیه که خیلی از شرکت ها و سرویس‌هارو دچار اخلال کرده، من تجربه شخصی‌م اینه که تا جایی که امکانش هست سمت سرور همه چیز رو utc ذخیره کنم. سمت کلاینت وظیفه‌ش اینه که utc رو به localtime کاربر تبدیل کنه.
نه تنها تلاش می‌کنم که همه چیز رو utc ذخیره کنم، بلکه باز ترجیح میدم جای datetime همه چیز timestamp ذخیره بشه، حتی در دیتابیس، تنها بدی‌ش اینه که داده‌های دیتابیس خیلی خوانا نیست که باید دید این قضیه چقدر برای بیزینس اهمیت داره.
ولی اگه مقدور هست ترکیب utc و timestamp به نظرم یه ترکیب خیلی امن و جوابه.
الانم اگه سرویسی دارید که روی پروداکشنه حتما چک کنید که مشکلی نداشته باشه.
با این دستور در ترمینال سرور یا container میتونید متوجه بشید که زمان رو داره با ۳ و نیم محاسبه میکنه برای ایران یا ۴ و نیم
TZ=Asia/Tehran date
البته بهتره که یه timestamp خاص رو بهش بدید چک کنه
TZ=Asia/Tehran date -d @1679520696
این عدد 1679520696 رو هم میتونید اینطوری بدست بیارید
date +%s
چک کردن سرور و کانتینر صرفا کافی نیست، باید ببینید توی کد اپلیکیشن تون دارید چیکار میکنید، مثلا میدونم که برای گولنگ همین تست کافیه اگه کار عجیب غریبی تو کد نکرده باشید!
اما ممکنه زبان هایی مثل جاوا یا php چالش‌های خاص خودشون رو داشته باشن.
همچنین باید دیتابیس هارو هم چک کنید، مثلا برای mysql میتونید از این دستور کمک بگیرید
SELECT @@global.time_zone, @@session.time_zone;
که اگه بنویسه SYSTEM یعنی داره از تایم زون سیستمی که روش نصب شده استفاده میکنه، که باز میتونید با این دستور ببینید تایم زون سیستم چیه
SELECT @@system_time_zone;
که اگه نوشته شده باشه UTC تا حدودی خیالتون راحت میشه.
کلا مشکل تایم‌زون رو جدی بگیرید، چیز خطرناکیه، وقتی که دارید سرور کانفیگ میکنید یا سرویس دیتابیس و اپلیکیشن نصب میکنید، حتما مطمئن بشید که در مورد تایم‌زون سرویس یا سیستم عامل صراحتا یک سری دستور به دستورات پروسه دیپلوی‌تون اضافه کردید. این دستورات میتونه تو Dockerfile باشه یا کانفیگ‌های دیگه. ولی حتما جدی‌ش بگیرید. چون ممکنه تا مدت‌ها مشکلی براتون ایجاد نکنه اما سر بزنگاه، میتونه اذیت‌تون کنه.