චීනයේ සහ තායිලන්තයේ NocoBase පරිශීලකයන් අතර "වෙලාව 8 පැය පසුබැසී ඇත" කියන පැමිණිලි නිතරම දැනගත හැකිය. ඒක තේරෙන්නේ කාලකලාප (UTC+8) හෝ (UTC+9) අනුව වේලාව වෙනස් වීම නිසාය.
මෙම ගැටලුව නිවැරදිව තේරුම් ගැනීමට, ලේඛකයා NocoBase 2.x (අවලම්බ Docker images) දෙකක් PostgreSQL 16 සහ MySQL 8.4 සමඟ සකසා, REST API මගින් දත්ත ලියන සහ කියවන ක්රියාකාරකම් මැනීය. සර්වර් කාලය (TZ) කන්ටේනරයේ පරිසර විචල්යයෙන් පාලනය කරමින්, බ්රවුසර පාර්ශ්වයේ ප්රදර්ශනය නොලකුණු කරයි.
දත්ත වර්ගය අනුව සුරැකුම් විධි
- Datetime (with time zone) – නිශ්චිත මොහොත (උදා: ලොග්, සිදුවීම්).
- Datetime (without time zone) – කාලගුණය පමණක්, වෙනස් නොවන ගැලපීම.
- Date only – උපන්දිනය, අවසන් දිනය.
- Unix timestamp – පද්ධති සමීකරණය.
ලියාපදිංචි කළ "2026-07-12 09:00" අගය PostgreSQL හි timestamptz ලෙස 2026-07-12 09:00:00+09 සුරැකි අතර, MySQL හි DATETIME ලෙස 2026-07-12 09:00:00 සුරැකි විය. MySQL හි offset තොරතුරක් නොමැති බැවින්, සර්වර් කාලය වෙනස් කළ විට ඒම අගය වෙනත් අර්ථයක් ගනී.
MySQL පරිසරයේ TZ=UTC ලෙස සකස් කර "09:00" ලියූ පසු, පසුකාලීනව TZ=Asia/Tokyo (UTC+9) කරගත්තාම, එම ලේඛනයේ අර්ථය 9 පැය ගොඩක් ඉදිරියට (හෝ පසු) මාරු විය. එම වගුවේ බයිට් අංකය කිසිවක් වෙනස් නොවූ අතර, පද්ධතියේ පැවති කාලකලාපය මත පදනම්ව API ප්රතිචාර වෙනස් වුණි.
PostgreSQL හි timestamptz offset එක සුරැකි නිසා, එවැනි මාරු නොදැකී. ඒ නිසා, MySQL භාවිතා කරන NocoBase පරිසරයන්හි සර්වර් කාලය පළමු දිනයේම නිශ්චිතව තබා, වෙනස් නොකරන එකම ආකාරය වේ.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ බහුතරය UTC+5:30 කාලකලාපයේ සිටින නිසා, NocoBase භාවිතා කරන සංවර්ධකයින්ට මෙම ගැටලුව අතුරුදන් වීමේ අවදානම වැඩි. ඒ නිසා:
- සැලසුම්කරුවන් – දත්ත ගබඩා කාලය නිවැරදිව සුරැකීම මගින් ව්යාපාරික වාර්තා සහ ලොග් විශ්ලේෂණය විශ්වාසනීය වේ.
- ඉගෙනුම් සිසුන් – කාලකලාප වෙනස්වීමේ තාක්ෂණික මූලධර්මයන් ගැන වඩා හොඳ අවබෝධයක් ලැබේ.
- ව්යාපාර – MySQL භාවිතා කරන පද්ධති වල TZ එකම තබා, දත්ත අහිමි වීම හෝ වැරදි ගණනාවක් ඇති වීමේ අවදානම අඩු වේ.
දෙවනුව, PostgreSQL තෝරා ගන්නේ නම්, කාලකලාප ගැටළු සම්පූර්ණයෙන්ම ඉවත් කර, සංවර්ධනයේ අවධානය වෙනත් නවීන විශේෂාංග වලට යොමු කළ හැක.
අවසන් වශයෙන්, NocoBase පරිසරය සකස් කරන විට සර්වර් කාලය පළමු දිනයේම තීරණය කර, Docker compose ෆයිලයේ TZ පාරාමිතිය සමඟ ඒකක කරගත යුතුය. එසේම, MySQL වෙනුවට PostgreSQL භාවිතා කිරීම මෙම වර්ගයේ දෝෂ වලින් සුරක්ෂිත වේ.
