DateTime Nightmare: เมื่อเวลาไม่ตรงก็พังทั้งระบบ!

เวลาในระบบ ไม่ได้มีแค่ชั่วโมงกับนาที — แต่มันคือปัญหายากระดับนรกของสาย dev และ data ทุกคน

TL;DR

• คนละ Format → เวลาไม่ตรง เช่น 01/02/2024 คือ 1 ก.พ. หรือ 2 ม.ค.?
• ไม่ใส่ Timezone → ข้อมูลเพี้ยนทันทีเมื่อข้ามประเทศ
• ประเทศไทยไม่มี DST แต่หลายประเทศมี → Dev มักพลาดตรงนี้
• ไม่ normalize เวลาก่อนเปรียบเทียบ → Bug เพียบ

เวลา = ปัญหาอันดับต้น ๆ ในงาน dev/data

“ปัญหาเวลาเป็นเรื่องที่เจอบ่อยมาก โดยเฉพาะเวลาทำงานกับฐานข้อมูล, SQL, dashboard หรือ data pipeline ข้าม region”

ปัญหายอดฮิตเรื่องเวลา

1. Format ไม่ตรงกัน

• เช่น 01/02/2024 → คนไทยอ่านเป็น 1 ก.พ., คนสหรัฐอ่านเป็น 2 ม.ค.
• ควรใช้ YYYY-MM-DD หรือ ISO 8601 เช่น 2024-02-01T10:00:00+07:00 จะชัวร์สุด

2. Timezone หาย

• เก็บเวลาในระบบแต่ไม่มี timezone → เวลาเพี้ยนตอนแสดงผล
• วิธีที่ถูก: เก็บเป็น UTC, แล้วให้ frontend หรือ backend แปลงเป็น local ตาม user

3. DST (Daylight Saving Time)

• บางประเทศขยับเวลาขึ้น/ลงปีละ 2 ครั้ง
• เวลาอาจหายไปหรือซ้ำ → ทำให้ query ผิด, join หาย
• ควรใช้ไลบรารี timezone-aware เช่น luxon, date-fns-tz, หรือ Intl

ตัวอย่างที่ใช้ได้จริงใน Node.js

การแปลงเวลาแบบมี timezone ด้วย luxon

const { DateTime } = require('luxon');

// เวลา UTC ตอนนี้
const nowUTC = DateTime.utc();

// แปลงเป็นเวลาไทย
const bkkTime = nowUTC.setZone('Asia/Bangkok');

console.log(bkkTime.toFormat('yyyy-MM-dd HH:mm:ss ZZZZ'));

ถ้าใช้ date-fns-tz

const { format, utcToZonedTime } = require('date-fns-tz');

const now = new Date();
const timeZone = 'Asia/Bangkok';

const zonedDate = utcToZonedTime(now, timeZone);
const output = format(zonedDate, 'yyyy-MM-dd HH:mm:ssXXX', { timeZone });

console.log(output);

SQL ก็มีเรื่องเวลาเหมือนกัน

PostgreSQL:

SELECT now() AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Bangkok';

MySQL:

SELECT CONVERT_TZ(NOW(), 'UTC', 'Asia/Bangkok');

Bugs ที่เจอกันบ่อย

Best Practice สำหรับ dev/data

สรุป

เวลาในระบบไม่ได้เท่ากันเสมอ การจัดการเวลาแบบผิด ๆ อาจทำให้ข้อมูลทั้งระบบ “พัง”

อ้างอิง

• Data Clinic - Date Time เจ้าปัญหา
• Luxon Docs
• date-fns-tz
• ISO 8601