โจทย์ของโครงการ
เว็บนี้ต้องแสดงเดือนของผลงานเป็น พ.ศ. สำหรับผู้อ่านภาษาไทย และ ค.ศ. สำหรับภาษาอังกฤษ ส่วนเวลาที่เผยแพร่บทความต้องรักษาโซนเวลาให้ถูกต้อง หากแต่ละหน้าเขียนกติกาเหล่านี้เอง การตรวจและแก้ไขภายหลังจะยากขึ้น
แนวทางที่เราใช้
เราใช้ Chronera ผ่านตัวกลางจัดการวันที่ร่วมกัน เนื้อหาเก็บค่า Gregorian ISO ส่วนการอ่านค่า เลือกโซนเวลา และจัดรูปแบบอยู่ในตัวกลางนี้ แต่ละหน้าจึงใช้กติกาเดียวกัน พร้อมหน้าทดลองแยกสำหรับเปลี่ยนค่าและดูโค้ดคู่กับผลลัพธ์
ขอบเขตงาน
- ตัวกลางจัดการวันที่เผยแพร่ เดือนของผลงาน และเวลาของรายงาน
- แสดงภาษาไทย พ.ศ. และภาษาอังกฤษ ค.ศ. โดยไม่เปลี่ยนวันที่ต้นทาง
- ระบุโซนเวลาชัดเจนเมื่อจัดการ timestamp
- ตัวอย่างที่รันได้สำหรับแสดงปี เทียบโซนเวลา และบวกวัน
รายละเอียดการพัฒนา
วันที่เดียวกัน อ่านได้สองภาษา
ผลงานที่เสร็จในเดือนกันยายน 2026 ควรแสดงเป็น 09/2026 ในภาษาอังกฤษ และ 09/2569 ในภาษาไทย ทั้งสองค่าหมายถึงเดือนเดียวกัน การเปลี่ยนภาษาจึงควรเปลี่ยนเฉพาะรูปแบบที่เห็น ไม่ใช่วันที่ที่เก็บไว้
เราใช้หลักนี้กับการเชื่อม Chronera เนื้อหาเก็บวันที่ Gregorian ISO แล้วให้ตัวกลางจัดการวันที่อ่านค่าและแสดงผลด้วยปฏิทินและโซนเวลาที่ระบุชัด วันที่ไม่ถูกต้องจะไม่ผ่านการตรวจเนื้อหาก่อนเผยแพร่ ส่วนชุดทดสอบครอบคลุมวันอธิกสุรทิน การข้ามปี และเที่ยงคืนของไทย
ลอง Chronera พร้อมตัวอย่างโค้ดที่รันได้ เปลี่ยนวันที่ เทียบโซนเวลา หรือบวกวันข้ามปี แล้วคัดลอกโค้ดที่ให้ผลลัพธ์นั้นไปใช้ต่อได้
แยก “วันที่” ออกจาก “จุดหนึ่งบนเส้นเวลา”
เดือนของผลงานไม่จำเป็นต้องมีโซนเวลา แต่ timestamp จำเป็นต้องรู้ว่าอ้างอิงเวลาใด ตัวอย่างนี้เริ่มจากเวลา UTC ที่ระบุไว้ชัด แล้วแสดงค่าในกรุงเทพฯ เทียบกับ UTC:
import { parseInstant, formatWithPattern } from '@intech-software/chronera';
const instant = parseInstant('2026-10-18T17:30:00Z');
console.log(
formatWithPattern(instant, 'dd/MM/yyyy HH:mm', {
locale: 'th-TH',
calendar: 'buddhist',
numberingSystem: 'latn',
timeZone: 'Asia/Bangkok',
}),
);
console.log(
formatWithPattern(instant, 'dd/MM/yyyy HH:mm', {
locale: 'en-GB',
calendar: 'gregory',
numberingSystem: 'latn',
timeZone: 'UTC',
}),
);
ผลลัพธ์คือ 19/10/2569 00:30 และ 18/10/2026 17:30 วันที่ต่างกันเพราะกรุงเทพฯ อยู่ก่อน UTC แต่ทั้งคู่ยังหมายถึงเวลาเดียวกัน ตัวอย่างนี้ตรวจด้วยแพ็กเกจรุ่น 0.2.8 ไม่ได้อ้างอิง API จากสาขาพัฒนาที่เปลี่ยนได้ตลอด
“ไม่มี runtime dependencies” หมายถึงส่วนไหน
ข้อมูลแพ็กเกจที่เผยแพร่รุ่น 0.2.8 ระบุ dependencies เป็นอ็อบเจกต์ว่าง นี่คือขอบเขตของคำว่าไม่มี runtime dependencies ไม่ได้หมายความว่าเว็บไซต์ เครื่องมือ build หรือส่วนเชื่อมต่อเสริมทั้งหมดไม่มี dependencies
แพ็กเกจระบุ Zod, Valibot และ SuperJSON เป็น optional peer dependencies สำหรับส่วนเชื่อมต่อของแต่ละตัว หากใช้ส่วนเหล่านั้นต้องมีแพ็กเกจที่เกี่ยวข้องด้วย ตัวกลางวันที่ของเว็บนี้ไม่ได้ import ส่วนเชื่อมต่อเหล่านี้ ส่วน runtime ของแพ็กเกจกำหนด Node.js ตั้งแต่ 22.14 ขึ้นไป ขณะที่เว็บนี้ใช้ Node.js 24 และมีข้อกำหนดรุ่นขั้นต่ำของตัวเว็บสูงกว่าแพ็กเกจ
การใช้แพ็กเกจตอนรันน้อยลงไม่ใช่คำรับรองความปลอดภัย โค้ดของไลบรารี ส่วนเชื่อมต่อ เครื่องมือ build และสภาพแวดล้อมที่ deploy ยังต้องตรวจและอัปเดต การจัดรูปแบบภาษาและโซนเวลายังอาศัย Intl และข้อมูลของ runtime จึงต้องทดสอบกับสภาพแวดล้อมที่รองรับด้วย
ตัวเลขความเร็วต้องตรวจซ้ำได้
หน้านี้ไม่ระบุอันดับความเร็ว ขนาดบันเดิล หรือจำนวนชุดทดสอบตายตัว ตัวเลขเดิมยังไม่มีรายงานการรันที่ระบุเครื่อง runtime และ revision ให้ตรวจย้อนกลับ จึงยังใช้ยืนยันผลเปรียบเทียบที่ทำซ้ำไม่ได้
ใน repository มี ชุด microbenchmark ณ source revision ของรุ่น 0.2.8 แต่การมีชุดทดสอบไม่ใช่ผลวัด ก่อนเผยแพร่ตัวเลขต้องมีข้อมูลประกอบดังนี้:
- รุ่นแพ็กเกจ source commit และรุ่นที่แน่นอนของไลบรารีที่นำมาเปรียบเทียบ
- CPU หน่วยความจำ ระบบปฏิบัติการ และรุ่น Node.js / V8 ที่ใช้จริง
- คำสั่ง ชุดข้อมูล โซนเวลา การ warm-up วิธีเก็บตัวอย่าง และสถานะ cache
- ผลดิบจากการรันซ้ำ หน่วยและความแปรปรวน โดยแต่ละฝั่งต้องทำงานที่เทียบกันได้
- หากรายงานขนาดบันเดิล ต้องระบุ entry point การตั้งค่า bundler และวิธีบีบอัดด้วย
Microbenchmark วัดงานย่อยภายใต้เงื่อนไขนั้น ไม่ได้ยืนยันความเร็วในการโหลดเว็บนี้หรือประสิทธิภาพของระบบลูกค้า
แหล่งอ้างอิงและการนำไปใช้
Case Study นี้อธิบาย รุ่น 0.2.8 ที่เว็บไซต์ใช้อยู่ ไม่ได้อ้างว่าเป็นรุ่นล่าสุดหรือครอบคลุมทุกความสามารถของไลบรารี
- ข้อมูลรุ่นและ dependencies ที่เผยแพร่บน npm
- Source manifest ณ commit 5361d661
- เอกสาร ณ source revision เดียวกัน
- เปิดหน้าทดลองและคู่มือเริ่มต้น
เริ่มจากกติกาวันที่ที่ระบบของคุณต้องใช้จริง ลองในหน้าตัวอย่าง แล้วทดสอบกติกาเดียวกันใน runtime เป้าหมายก่อนนำแพ็กเกจไปใช้
ผลลัพธ์
- เว็บใช้งานแพ็กเกจ @intech-software/chronera รุ่น 0.2.8 โดยตรึงรุ่นไว้
- รวมกติกาวันที่ไว้ในจุดเดียว แทนการเขียนซ้ำในแต่ละหน้า
- มีหน้าทดลองสองภาษา แสดงโค้ดที่รันได้คู่กับผลลัพธ์
เทคโนโลยี
- TypeScript
- JavaScript
- ECMAScript Modules (ESM)
- Node.js
- Intl
- Astro
- Vitest
- Playwright

