با ارائه net core.، شاهده استفاده‌ی گسترده از DateTimeOffset بجای DateTime بودیم و این استفاده به مرور در کدهای خودمان هم ورود کرد. DateTimeOffset به شما این اجازه را میدهد که دقیقا بدانید ساعت وارد شده در سیستم، دقیقا مربوطه به چه منطقه زمانی است. در پروژه‌ای که مدتی است با نسخه‌ی Asp.net core 3.1 در حال طراحی و به روزرسانی بخش‌های مختلف آن هستیم، یکی از موارد، سیستم زمانی آن است که باید در زمان‌های مناسب و مدنظر کاربر، فعالیت‌های تنظیم شده‌ی توسط کاربر را به انجام برساند.

در اینجا سامانه به صورت Paas آغاز به فعالیت کرد. در این نوع سیستم‌ها، تاریخ و ساعت سرور بر اساس منطقه‌ی زمانی صفر، یعنی گرینویچ یا نصف النهار مبدا تنظیم شده‌است. یعنی زمانی که شما ساعت سیستم را دریافت میکنید، Offset بر روی صفر تنظیم شده‌است و اگر کاربر تهران (ایران) ساعتی را بخواهد تنظیم کند، این تاریخ حتما باید یک آفست 3.5 داشته باشد تا محاسبات زمانی سیستم دقیق کار کند؛ در غیر اینصورت سه ساعت و نیم زودتر، فعالیت موردنظر آغاز میگردد و باعث خطا و بی اعتبار شدن سامانه میگردد.

 همچنین در بعضی کشورهای مانند ایران، Daylight Saving Time یا به اختصار DST نیز پیاده سازی میشود که در ین حالت در کشور مربوطه، نیمه اول سال که هوا گرم‌تر است ساعت‌ها یک ساعت به جلو کشیده شده و با آغاز روزهای سرد سال، ساعت بجای قبلی خود باز میگردد و به همین دلیل، آفست زمانی آن 4.5 میباشد که البته ممکن است بنا به دلایلی این DST اجرا نگردد که  بیش از ده سال پیش کشور ما نیز چنین تجربه‌ای را چند سالی داشت.

به همین دلیل باید این موضوع تغییر آفست را جدی گرفت. حال در سامانه‌ی ما گاها افرادی هستند که در خارج از کشور با آن کار میکنند و از آنجا که سامانه بر اساس ساعت تهران این فعالیت را انجام میدهد، باید در این قسمت به روزرسانی‌هایی را به انجام میرساندیم. بدین ترتیب در قسمت پروفایل کاربر، لیستی به نام منطقه زمانی قرار دادیم تا بر اساس آن، کاربر بتواند منطقه زمانی خود را انتخاب کند تا از این پس، زمان خود را بر اساس زمان تهران مشخص نکند. پس با استفاده از کلاس موجود در دات نت TimeZoneInfo  لیستی از TimeZone‌ها را به دست آوردم که هر timezone شامل ID، نام نمایشی، میزان آفست آن منطقه، آیا شامل DST میگردد یا خیر و ... میشود.

 در این حالت برای هر کاربر، Zone ID را ذخیره کرده و با هر بار استفاده بر اساس ZoneId، اطلاعات آن منطقه زمانی را به دست می‌آوردم. همه چیز درست کار میکرد ولی زمانیکه سامانه توسط داکر روی سرویس‌های Paas اجرا شد، در این حالت چون سیستم مذکور یک لینوکس است که توسط Nginx اجرا میگردد و اینکه TimeZoneInfo یک سیستم WindowsBased است، به مشکل برخورد کرد و نتوانست ZoneID مورد نظر را در سیستم بیابد. سیستم‌های دیگر مانند لینوکس، از ساختاری با نام IANA  میباشد که توسط ICANN حمایت میشود و دیتابیس‌های به روز آن در این آدرس قرار دارد.  به همین علت سیستم مجددا RollBack شد تا آن را اصلاح نماییم.

جهت اصلاح این مشکل سه مورد زیر را بررسی کردم:

یک. استفاده از کتابخانه مبدل منطقه زمانی: این کتابخانه تبدیل حالت‌های زمانی از ویندوز به IANA و بالعکس را دارد. همچنین این امکان را به شما میدهد که به راحتی با وارد نمودن ZoneId به هر شکلی که وارد شود، چه به صورت ویندوزی و چه به صورت IANA باشد، خروجی TimeZoneInfo مورد نظر را تامین مینماید. البته در سیستم عامل ویندوز همان شکل قبل را دارد ولی در حالت لینوکسی، نام نمایشی مناطق شکل مناسبی ندارد و فقط بیشتر به شکل اختلاف زمانی میباشد که دو مرتبه تکرار شده است.

دو. استفاده از کتابخانه NodaTime: کتابخانه NodaTime، کتابخانه‌ی خوشنامی در مورد مسائل تاریخ و ساعت میباشد و همچنین قابلیت مناطق زمانی را بر اساس سیستم IANA فراهم میکند 

سه. ارتقا پروژه به دات نت 6:  تیم دات نت، در نسخه‌ی ،6 در زمینه‌ی تاریخ و ساعت بهبود‌های فراوانی داشته‌اند که تایپ‌های جدید DateOnly و TimeOnly نیز نمونه‌هایی از آن میباشد ولی بهبودهایی هم در زمینه TimeZone‌ها نیز صورت گرفته‌است و از حالت WindowsBased به حالت CrossPlatform تغییر یافته‌است. در حال حاضر در صورتیکه در نسخه 6، شما از مناطق زمانی چه در ویندوز و چه در لینوکس استفاده کنید، یا اینکه در یک سیستم IANA از ZoneId‌های ویندوزی استفاده کنید و یا بالعکس، هیچ مشکلی وجود ندارد.

با توجه به این موضوع، ما سیستم را از نسخه‌ی 3.1 به نسخه 6 به روزرسانی کردیم و به راحتی و بدون تغییر کدها توانستیم مناطق زمانی را به راحتی بدست آوریم. البته این نکته را باید مدنظر داشته باشید که در سیستم ویندوزی، همه چیز مطابق قبل است ولی در یک سیستم مبتنی بر IANA، ممکن است بعضی از نام‌های نمایشی تکراری باشند، ولی ZONEID‌ها متفاوت هستند؛ مثلا برای ایران دو منطقه زمانی، یا برای ترکیه سه یا چهار منطقه زمانی وجود داشت؛ با نام‌های نمایشی یکسان ولی با ZoneId‌های متفاوت به شکل Iran و دیگری به شکل Asia/tehran بود و ترکیه هم با چند نام شهر متفاوت است.

ولی با شما در این مورد که خیلی کند است مخالف ام. 

من تقریبا 1سال است که با گریدل کار میکنم و ماکسیمم زمان بیلد پروژه 10 الی 15 ثانیه است . 

شما میتوانید این زمان را حتی با آفلاین کردن سیستم گریدل به 2 ثانیه کاهش بدید . 

برای آموزش بیشتر در مورد گریدل می‌توانید به این آموزش رجوع کنید . gradle-for-android-and-java

از آنجائیکه مدتی قسمتی از کارم مرتبط بود به طراحی ایمیل‌های خودکار برای برنامه‌های تهیه شده (مثلا، ایمیل‌های مرحله به مرحله یک گردش کاری ... اطلاع رسانی‌های خودکار از وضعیت داده‌ها،‌ گزارشاتی از برنامه‌ها که به صورت خبرنامه‌های ایمیلی در بازه‌های زمانی مشخصی به اشخاص مشخص شده ارسال می‌شد و غیره)، لازم می‌دونم خلاصه‌ای از تجربیات برخورد با کاربران را در این مورد در ادامه ذکر کنم، شاید مفید باشد.

1) حتما در انتهای ایمیل خودکار ارسالی، ساعت و تاریخ شمسی ارسال پیام را نیز ذکر کنید.
عموما از آنجائیکه سیستم استاندارد ارسال ایمیل بر اساس تاریخ میلادی است و تقریبا تمام کلاینت‌های دریافت ایمیل موجود نیز توانایی شمسی سازی تاریخ دریافت و ارسال ایمیل را ندارند (مگر با یک سری افزونه و یا دستکاری در سیستم عامل که آنچنان خوشایند و مرسوم نیست)، ذکر تاریخ شمسی در انتهای پیام بسیار مفید خواهد بود و در اکثر اوقات استناد به ایمیل‌های دریافت شده بر اساس تاریخ دریافت آن‌ها است.

2) سعی کنید از بکارگیری عناوین (subject) ثابت جهت ارسال ایمیل‌های خودکار پرهیز کنید.
دقیقا یادم میاد زمانیکه برای مدیر عامل شرکتی سه بار پشت سرهم ایمیلی با یک عنوان ارسال شده بود بنده را بازخواست کردند که چرا برنامه‌ی شما ایمیل تکراری ارسال می‌کند!
بله، سعی می‌کنند محتوا را از روی عنوان ایمیل حدس بزنند و زمانیکه یک عنوان ثابت را برای ایمیل‌های خودکار خود انتخاب کردید، تکراری به نظر خواهند رسید یا حتی ممکن است به اشتباه پیش از خوانده شدن حذف شوند.
برای مثال فرض کنید ایمیل ارجاع کاری را قرار است به صورت خودکار ارسال کنید. انتخاب عنوان ثابت برای مثال "ارجاع کار جدید" اشتباه است! این عنوان باید بر اساس نوع کار هر بار به صورت پویا متغیر باشد؛ مثلا: "ارجاع کار جدید: از طرف : ... ، موضوع: ... ، درجه اهمیت: ..." که این سه نقطه‌ها باید توسط برنامه هر بار پر شوند.

3) هر چه می‌توانید اطلاعات بیشتری را توسط یک ایمیل خودکار منتقل کنید.
مورد قبل را در نظر بگیرید. ذکر "ارجاع کار جدید ..." در عنوان و سپس مجددا ذکر همین عنوان به عنوان بدنه‌ی ایمیل خودکار به زودی ایمیل‌های شما را تبدیل به نوعی Spam آزار دهنده خواهد کرد. کار جدیدی ارجاع شده است؟ آیا می‌توان خلاصه‌ای از این کار را به همراه ایمیل نیز ارسال کرد تا کاربر حتما برای مشاهده‌ی ریز جزئیات کار به برنامه مراجعه نکند و این ایمیل واقعا ارزش مطالعه را داشته باشد و سبب تسریع در انجام کارها شود؟
برای مثال ذکر کلی این مورد که درخواست مرخصی جدیدی را باید تائید یا رد کنید، کافی نیست. ریز جزئیات مرخصی را هم به همراه ایمیل ارسال کنید.

4) ایمیل شما باید حاوی لینکی جهت باز کردن برنامه‌ی تحت وب مرتبط نیز باشد.
کاری ارجاع شده است؟ بهتر است لینک پویایی را جهت هدایت کاربر به صفحه‌ی مرتبط رسیدگی به همان کار ارجاعی ارسال کنید. به این صورت زحمت او را کمتر کرده و یک مرحله گزارش گیری را حذف خواهید کرد. یا حداقل یک محل مراجعه‌ی کلی بعدی را به این صورت می‌توان ارائه داد.

5) از بکارگیری قسمت from ایی مانند DoNotReply@Site.Com خودداری کنید.
کاربر دریافت کننده‌ی ایمیل باید بداند که در صورت وجود مشکل باید به کجا مراجعه کند؟ چه کسی این ایمیل را ارسال کرده؟
هرچند برنامه به صورت خودکار تمام قسمت‌های این ایمیل ارسالی را تهیه می‌کند اما اگر خبرنامه‌ی تنظیم شده‌ای نیست، حتما شخص ارسال کننده‌ای دارد. یا حداقل یک ایمیل عمومی را برای این مورد تنظیم کنید (ایمیلی که وجود خارجی داشته و هر از چندگاهی بررسی می‌شود).

6) رنگ زمینه و اندازه‌ی قلم مناسبی را انتخاب کنید.
دقیقا برای هر کدام از موارد ذکر شده چندین بار مشکل داشته‌ام! عموما کسانی که ایمیل‌ها را دریافت می‌کنند سن و سال دار هستند. بنابراین انتخاب فونت tahoma با اندازه‌ی 8 یا pt 7 سبب توبیخ زود هنگام شما خواهد شد!
همچنین هر چه ساده‌تر بهتر. دقیقا مشکلات از زمانی آغاز می‌شوند که طرحی را انتخاب کنید یا رنگی را برای زمینه بکار ببرید. اینجا است که هر روز یک سلیقه‌ی تحمیلی را باید پذیرا باشید.

7) دقیقا مشخص کنید که ایمیل دریافتی آیا رونوشت‌ است یا خیر!
همان مبحث ارجاع کار را در نظر بگیرید. پس از اینکه سیستم راه اندازی شد، مدیر یکی از قسمت‌ها چند روز بعد این درخواست را "حتما" ارسال خواهد کرد: رونوشت تمام کارهای ارجاعی به کلیه پرسنل بخش و همچنین ریز اقدامات آن‌ها باید برای بنده نیز ارسال شود.
در اینجا تنها افزودن قسمت CC به ایمیل‌های خودکار کفایت نمی‌کند. حتما به صورت درشت در بالای ایمیل، قبل از شروع بدنه ذکر کنید که ایمیل دریافتی یک رونوشت است. در غیر اینصورت باید پاسخگوی علت دریافت ایمیل‌هایی باشید که به درخواست خودشان CC شده است!

8) از ایمیل‌های خودکار برنامه log تهیه کنید.
بارها به این مساله برخورد کرده‌ام که اشخاص برای شانه خالی کردن از انجام کار محوله، سعی در تخریب کار شما خواهند داشت. خیلی ساده عنوان می‌کنند که ایمیلی را دریافت نکرده‌اند. حالا شما بیاید ثابت کنید که اگر سیستم مشکل داشت کلا برای هیچ کسی ایمیل ارسال نمی‌شد، نه فقط برای شما. در اینگونه مواقع وجود یک لاگ از ایمیل‌ها (ثبت در بانک اطلاعاتی) و ارجاع به آن‌ها بسیار راه گشا است.

9) راهی را برای خلاص شدن از شر دریافت ایمیل‌های خودکار نیز پیش بینی کنید!
همان مورد 7 را در نظر بگیرید. دو روز اول خیلی ذوق خواهند کرد! روز سوم وقتی انبوهی از ایمیل‌ها را دریافت کردند، مشکل شما هم شروع خواهد شد. بنابراین امکان تنظیم دریافت یا عدم دریافت ایمیل را حتما در برنامه قرار دهید. یا حداقل نحوه‌ی ایجاد یک پوشه جدید و فیلتر کردن ایمیل‌های رسیده و هدایت خودکار آن‌ها به این پوشه‌ی جدید را آموزش دهید.


خوب! حالا به نظر شما این ایمیل خودکار ارسالی سایت IDevCenter که اخیرا اضافه شده است چه نمره‌ای را کسب می‌کند؟



- تاریخ شمسی در انتهای ایمیل ندارد.
- عنوان‌ها ثابت هستند.
- هیچ جزئیاتی ارائه نشده است.
- لینک مرتبط دارد.
- قسمت from مناسبی دارد.
- ساده است؛ خوب است! فقط اندازه قلم آن بهتر است یک شماره بزرگتر شود.
- بحث رونوشت اینجا مورد ندارد.
- بحث لاگ ... شخصی است.
- امکان تنظیم دریافت ایمیل پیش بینی شده است.
نمره از 7 : 3.5

UTC is enough for everyone ... right?