เครื่องมือเวลา
所有时间均基于您设备的本地时钟
เครื่องมือเวลาออนไลน์ฟรี รองรับ Unix Timestamp Conversion, DateTime Conversion, World Clock Viewing, Timezone Conversion และ Countdown Setup เหมาะสำหรับ Development Debugging, Cross-timezone Collaboration และ Schedule Management
คำแนะนำที่เกี่ยวข้อง
กรณีการใช้งาน
- แปลง Unix Timestamp เป็น Readable DateTime เมื่อ Development Debugging เพื่อตรวจสอบ Log Issues
- เปรียบเทียบ World Time เพื่อจัด Meeting และ Launch Windows เมื่อ Cross-border Team Collaboration
- ตั้ง Countdown สำหรับ Launch Events หรือ Project Deadlines เพื่อ Time Management
- Validate Second-level และ Millisecond-level Timestamps ว่าถูกต้องหรือไม่เมื่อทำ API Integration
วิธีการใช้งาน
- เลือก Function Module (Timestamp Conversion, World Clock หรือ Countdown)
- กรอก Timestamp, เลือก Timezone หรือตั้ง Target Date
- เครื่องมือคำนวณและแสดง Time Results ที่สอดคล้องกัน
- คัดลอก Time Results สำหรับ Debugging, Scheduling หรือ Schedule Management
คุณสมบัติ
- ดู World Time รวมศูนย์:เปรียบเทียบ Cities และ Timezones หลายแห่งเร็ว เหมาะสำหรับ Cross-region Communication และ Scheduling
- Timestamp Conversion มีประโยชน์บ่อย: Development Debugging, Log Troubleshooting และ API Integration สามารถทำ Time Conversion ได้เร็ว
- Countdown แสดงเห็นภาพชัดเจนกว่า: เหมาะสำหรับ Activity Milestones, Launch Plans และ Important Date Reminders Time Management Scenarios
- ใช้ได้ทันทีออนไลน์: ไม่ต้องใช้ Local Scripts และ Plugins เปิดหน้าเว็บก็สามารถทำ Time Operations ทั่วไป
เลือกรูปแบบเวลาและเครื่องมืออย่างไรดี?
ตอนเขียนโค้ด เรียก API หรือ debug log มี 2 คำถามที่มักสับสนที่สุด: ควรส่ง/เก็บเวลาในรูปแบบไหน? เครื่องมือเวลาหลายตัวในเว็บนี้ควรใช้อันไหน? ดู 2 ตารางนี้แล้วตัดสินใจได้ทันที
Unix Timestamp vs ISO 8601 / RFC 3339 vs String รูปแบบ Local: ควรใช้อันไหน?
การส่ง API, การเก็บในฐานข้อมูล, การแสดงผล log, และการแสดงผลบน frontend มีทางเลือกที่เหมาะสมแตกต่างกัน การเลือกผิดจะทำให้ timezone ผิดพลาด อ่านยาก หรือเกิด bug parsing
| รูปแบบ | ตัวอย่าง | ข้อมูล Timezone | กรณีที่แนะนำ | ข้อผิดพลาดที่พบบ่อย |
|---|---|---|---|---|
Unix Timestamp (วินาที) | 1711699200 | ✅ ไม่มี timezone (จำนวนวินาที UTC) | การส่ง backend API, การเก็บใน MySQL/Redis, เวลา log, การตรวจสอบข้ามระบบ | ⚠️ ต้องระบุหน่วยวินาที/มิลลิวินาทีให้ชัดเจน; ผิดหน่วย = ต่างกัน 1000 เท่า = ผิดไป 40+ ปี |
Unix Timestamp (มิลลิวินาที) | 1711699200000 | ✅ ไม่มี timezone (จำนวนมิลลิวินาที UTC) | JavaScript `Date.now()`, การติดตาม event บน frontend, log ความแม่นยำสูง Java/Go | ⚠️ ตัวเลข 13 หลักถ้า parse เป็นวินาทีจะได้เวลา 50,000+ ปีข้างหน้า |
ISO 8601 / RFC 3339 | 2024-03-29T00:00:00Z | ✅ มี timezone (Z=UTC หรือ +07:00) | JSON API response, ข้อมูลจำเพาะ OpenAPI, output log มาตรฐาน, การทำงานร่วมกันข้ามภาษา | ⚠️ ต้องลงท้ายด้วย `Z` หรือ offset timezone มิฉะนั้นจะถูก parse เป็นเวลาท้องถิ่น |
String รูปแบบ Local | 2024/3/29 14:30 | ❌ ไม่มี timezone (local โดยปริยาย) | ใช้สำหรับแสดงผลให้ผู้ใช้ดูบน frontend เท่านั้น, ส่งออก Excel/CSV | ❌ **อย่าเด็ดขาด**ใช้ใน API หรือฐานข้อมูล ผลลัพธ์ parsing ข้าม timezone/ข้าม browser ไม่สอดคล้องกัน |
ควรเลือกเครื่องมือเวลาในเว็บนี้อันไหนดี?
เว็บนี้มีเครื่องมือที่เกี่ยวข้องกับเวลา 4 ตัว; ฟีเจอร์มีการทับซ้อนกันแต่จุดประสงค์ต่างกัน เลือกให้ตรงกับสิ่งที่คุณกำลังจะทำ จะได้ไม่ต้องเสียเวลาลองผิดลองถูก
| เครื่องมือ | ฟีเจอร์หลัก | เหมาะสำหรับ | ไป |
|---|---|---|---|
หน้านี้ เครื่องมือเวลา 3-in-1 | World Clock + แปลง Timestamp + Countdown, 3 ฟีเจอร์ในหน้าเดียว | ดูเวลาประจำวัน, แปลง timestamp อย่างรวดเร็ว, countdown ชั่วคราว, จัดตาราง meeting ข้าม timezone | หน้าปัจจุบัน |
ตัวแปลง Unix Timestamp | เน้นที่การแปลง Unix Timestamp ↔ วันที่/เวลา รองรับ batch และเวลาสัมพัทธ์ | debug การพัฒนา, แปลงจำนวนมาก, ต้องการความแม่นยำถึงวินาที/มิลลิวินาที, ดูเวลาสัมพัทธ์ (เช่น "2 ชั่วโมงที่แล้ว") | ไป |
ตัวสร้าง Cron Expression | สร้าง Cron expression สำหรับงาน scheduled แบบภาพ (5-field/6-field/7-field) | เขียน Linux crontab, จัดตารางงาน scheduled, การตั้งค่า cron Quartz/Spring | ไป |
ตัวตรวจสอบ Cron Expression | Parse Cron expression ที่มีอยู่ แสดง N ครั้งการทำงานถัดไป ตรวจสอบข้อผิดพลาด | แก้ไขปัญหา cron job ไม่ทำงาน, ตรวจสอบ syntax Cron, ดูเวลา trigger ครั้งถัดไป | ไป |
Best Practices
สำหรับการส่ง API / เก็บในฐานข้อมูล ให้ใช้ Unix Timestamp หรือ ISO 8601 ที่มี Z เสมอ
สำหรับการส่ง API และการเก็บในฐานข้อมูล มีกฎทอง 2 ข้อ：**（1）ใช้ Unix Timestamp（วินาทีหรือมิลลิวินาที）สำหรับฟิลด์ที่ใช้คำนวณ การเปรียบเทียบตัวเลขทำได้โดยตรง ไม่มีความกำกวมเรื่อง timezone；（2）ใช้ ISO 8601 ที่มี Z ต่อท้าย（เช่น `2024-03-29T00:00:00Z`）สำหรับ log และฟิลด์ที่อ่านง่าย ทั้งคนและเครื่องอ่านได้ และชัดเจนว่าเป็น UTC**。**อย่าเด็ดขาด**ส่งหรือเก็บ string รูปแบบ local เช่น `2024/3/29 14:30` หรือ `2024-03-29`——parser Date ใน browser และภาษาต่างๆ มีการสมมติ timezone ที่แตกต่างกันสำหรับ string ดังกล่าว Safari แม้จะส่งคืน Invalid Date โดยตรงก็ได้
ตารางเปรียบเทียบการเลือกรูปแบบเวลาเอกสาร API Frontend/Backend ต้องระบุหน่วย Timestamp (วินาที/มิลลิวินาที) ให้ชัดเจน
**นี่คือสาเหตุอันดับหนึ่งของ bug ที่เกี่ยวกับเวลา**。ระดับวินาทีคือตัวเลข 10 หลัก（เช่น `1711699200`）, ระดับมิลลิวินาทีคือตัวเลข 13 หลัก（เช่น `1711699200000`）, ทั้งสองต่างกัน 1000 เท่า——มิลลิวินาทีถูก parse เป็นวินาทีจะได้เวลา 50,000+ ปีข้างหน้า, วินาทีถูก parse เป็นมิลลิวินาทีจะย้อนไปปี 1970. ในชื่อฟิลด์หรือคำอธิบายของเอกสาร API **ต้องระบุหน่วยอย่างชัดเจน**（ตัวอย่างเช่น `created_at: Unix Timestamp ระดับมิลลิวินาที`）. อย่า「เดาจากจำนวนหลัก」. เมื่อ frontend ได้รับ timestamp สิ่งแรกที่ต้องทำคือตรวจสอบจำนวนหลัก: ถ้า 10 หลักให้คูณ 1000, ถ้า 13 หลักให้ใช้โดยตรง
ผลลัพธ์การแปลง timestamp ไม่ถูกต้อง ต่างกันหลายปี?สำหรับการจัดตาราง Meeting / Event ข้าม Timezone ให้ใช้ UTC เป็นเกณฑ์การสื่อสารเสมอ
เวลาประชุมกับทีมข้ามชาติ**อย่าเคยพูดว่า 「เราประชุมบ่าย 3 โมงนะ」**——บ่าย 3 โมงของปักกิ่งคือตี 3 ของนิวยอร์ก ตี 7 ของลอนดอน; การสมมติ timezone ของอีกฝ่ายจะทำให้เวลาประชุมผิดพลาดแน่นอน วิธีที่ถูกต้อง: **ขั้นแรกแปลงเวลาเป็น UTC（เช่น UTC 07:00）แล้วบอกให้ชัดเจน จากนั้นปล่อยให้แต่ละฝ่ายแปลงเป็นเวลาท้องถิ่นเอง**, หรือส่ง string ISO 8601 ที่มี timezone โดยตรง（เช่น `2024-03-29T07:00:00Z`）ให้ซอฟต์แวร์ปฏิทินแปลงอัตโนมัติ ก่อนประชุมข้ามชาติ ให้ใช้ World Clock ในหน้านี้ดูเวลาเมืองของผู้เข้าร่วมทุกคนพร้อมกัน เลือกช่วงเวลาที่ overlap กับช่วงกลางวันทำการของทุกคน
สามารถใช้จัดตารางประชุมข้าม timezone ได้ไหม?สำหรับพื้นที่ที่มี DST ให้ใช้ ID Timezone (America/New_York) อย่า Hardcode Offset UTC คงที่
เวลามาตรฐานนิวยอร์กคือ UTC-5, DST คือ UTC-4; เวลามาตรฐานลอนดอน UTC+0, DST UTC+1; ประเทศส่วนใหญ่ในยุโรปมีการเปลี่ยน DST **ถ้าคุณเขียน `offset: -5` ในโค้ดเพื่อแสดงเวลานิวยอร์ก ในวันที่เปลี่ยน DST เวลาทั้งหมดจะผิดไป 1 ชั่วโมง**。วิธีที่ถูกต้องคือใช้ IANA timezone ID（เช่น `America/New_York`, `Europe/London`, `Asia/Shanghai`）และปล่อยให้ `Intl.DateTimeFormat` หรือไลบรารี timezone ฝั่งเซิร์ฟเวอร์จัดการ DST โดยอัตโนมัติ เครื่องมือนี้ใช้ IANA timezone ID, DST จะเปลี่ยนโดยอัตโนมัติ ไม่ต้องปรับด้วยตนเอง
DST ได้รับการจัดการโดยอัตโนมัติหรือไม่?IANA Time Zone Database อย่างเป็นทางการเวลาเป้าหมาย Countdown ให้ใช้ UTC หรือ Timezone ที่ชัดเจน หลีกเลี่ยงคำพูดคลุมเครือเช่น 「พรุ่งนี้กี่โมง」
สำหรับสถานการณ์เช่น countdown เปิดตัว, การเปิดอีเวนต์, เริ่มไลฟ์**เวลาเป้าหมายต้องกำหนดเป็นเวลา UTC หรือจุดเวลาเฉพาะที่มี timezone**（เช่น `2024-06-01T00:00:00+07:00`）และอย่าใช้คำพูดที่คลุมเครือเช่น 「8 โมงเช้าพรุ่งนี้」 หรือ 「เช้าวันจันทร์หน้า」 เหตุผล: 「8 โมงเช้าพรุ่งนี้」คำนวณตาม timezone ของใคร? Timezone ของเซิร์ฟเวอร์หรือ timezone ท้องถิ่นของผู้ใช้? ในวันที่เปลี่ยน DST 「พรุ่งนี้」คือ 23 ชั่วโมงข้างหน้าหรือ 25 ชั่วโมงข้างหน้า? คำอธิบายที่คลุมเครือจะทำให้เกิด bug แน่นอนเมื่อ deploy ข้าม timezone หรือเปลี่ยน DST หลังจากตั้งค่า countdown แล้ว ให้ใช้เครื่องมือนี้ตรวจสอบว่าจำนวนวันที่เหลือตรงตามที่คาดไว้หรือไม่
อย่า new Date โดยตรงด้วย String YYYY-MM-DD ที่ไม่มี Suffix —— Parsing ใน Browser ไม่สอดคล้องกัน
ใน JavaScript ผลลัพธ์ parsing ของ `new Date('2024-03-29')` **ไม่สอดคล้องกัน**ใน browser ต่างๆ: Chrome/Edge/Firefox ถือว่าเป็น UTC 0 นาฬิกา แต่ Safari ถือว่าเป็น**0 นาฬิกา timezone ท้องถิ่น** ซึ่งทำให้ต่างกัน（สำหรับเวลาไทย）7 ชั่วโมงขึ้นไป วิธีที่ถูกต้อง: **（1）เพิ่มเวลาและ Z: `new Date('2024-03-29T00:00:00Z')` เพื่อระบุ UTC อย่างชัดเจน;（2）ด้วย timezone ท้องถิ่น: `new Date(2024, 2, 29, 0, 0, 0)` ใช้ constructor แบบตัวเลข;（3）ใช้ไลบรารีเช่น dayjs/date-fns สำหรับการ parsing แบบรวมศูนย์**。ข้อผิดพลาดนี้เป็นหนึ่งในสาเหตุของ bug เวลาบน frontend ที่ซ่อนอยู่มากที่สุด สามารถค้นพบได้จากการทดสอบบนอุปกรณ์ Safari จริงเท่านั้น
MDN - ข้อควรระวังในการ Parse Dateคำถามที่พบบ่อย
Time Tool เหมาะกับสถานการณ์ไหน?
เหมาะสำหรับดูเวลาปัจจุบันใน Timezones ต่างๆ, Cross-border Collaboration Scheduling, Development Timestamp Debugging และตั้ง Activity Countdown
สามารถแปลง Unix Timestamp และ DateTime หากันได้ไหม?
ได้ Second-level และ Millisecond-level Timestamps กับ Standard DateTime Conversion เป็นความต้องการที่พบบ่อยใน Development และ Testing
ทำไม Cross-timezone Collaboration ถึงต้องการ World Clock?
เพราะ Work Hours, Meeting Times และ Launch Windows ในแต่ละภูมิภาคต่างกัน การเปรียบเทียบ World Time ล่วงหน้าช่วยลด Communication Errors
Countdown เหมาะกับ Activities และ Project Milestones ไหม?
เหมาะมาก Launch Events, Launch Days, Exam Days และ Project Deadlines สามารถติดตาม Remaining Time ได้เห็นภาพชัดเจนกว่าด้วย Countdown
- จำลองตาบอดสี
- ตัวแปลงสี
- เครื่องมือแปลง htaccess เป็น Nginx
- ตัวแปลง SQL
- ตัวแยกคุกกี้
- ตัวสร้าง Cron
- ตัวตรวจสอบ Cron
- จัดรูปแบบ CSS
- บีบอัด CSS
- CSV เป็น Excel
- แปลงค่าเงิน
- ตรวจสอบความแตกต่าง
- สร้าง Favicon
- จัดรูปแบบ XML
- ตัวแปลงเลขฐานสิบหก
- จัดรูปแบบ HTML
- บีบอัด HTML
- HTML เป็น Markdown
- แปลง Markdown เป็น HTML
- ตัวจัดรูปแบบ JavaScript
- บีบอัด JS
- เครื่องมือจัดรูปแบบ JSX
- บีบอัด JSX
- การจัดกลุ่มคำหลัก
- เครื่องมือสร้าง Lorem Ipsum
- สร้างตาราง Markdown
- เครื่องมือสร้าง Meta Tag
- เครื่องมือสร้างรหัสผ่าน
- เครื่องมือตรวจสอบความแข็งแรงของรหัสผ่าน
- เครื่องสร้าง QR Code/บาร์โค้ด
- เครื่องมือทดสอบ Regex
- สร้าง URL Slug
- สร้าง SQL
- เครื่องมือจัดรูปแบบ SQL
- เครื่องนับคำ
- เครื่องมือเวลา
- จัดรูปแบบ TS
- บีบอัด TS
- จัดรูปแบบ TSX
- บีบอัด TSX
- ตัวแปลง Unix Timestamp
- เครื่องมือสร้าง UUID
- จัดรูปแบบ YAML
- Case Converter