JavaScript Temporal กำลังมา

 (developer.mozilla.org)
2 คะแนน โดย GN⁺ 2025-01-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อ็อบเจ็กต์ Temporal ใหม่ของ JavaScript เริ่มถูกนำเข้าไปในรุ่นทดลองของเบราว์เซอร์แล้ว เป็นการเปลี่ยนแปลงที่มุ่งจัดการวันที่ เวลา ระยะเวลา และปฏิทินด้วย API ในตัวให้แม่นยำและสม่ำเสมอยิ่งขึ้น
  • Date เดิมทำให้ การจัดการเขตเวลาและการดีบัก เป็นเรื่องยาก เนื่องจากโครงสร้างที่เน้นเวลาท้องถิ่นของผู้ใช้กับ UTC, การ parse ที่ไม่เสถียร และพฤติกรรมแบบ mutable
  • Temporal แยก จุดเวลา เวลาในพื้นที่ และระยะเวลา ออกจากกันด้วย Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime, Temporal.Duration, Temporal.Now เป็นต้น และมีเมธอดยูทิลิตีกว่า 200 รายการ
  • ยังต้องใช้เวลาอีกระยะกว่าจะรองรับข้ามเบราว์เซอร์อย่างเสถียร โดยใน Firefox Nightly สามารถทดลอง Temporal ได้หลังเปิดการตั้งค่า javascript.options.experimental.temporal
  • สัปดาห์นี้ MDN เพิ่มเอกสาร Temporal มากกว่า 270 หน้า และในหน้าเอกสาร TC39 ที่มี @js-temporal/polyfill สามารถรันตัวอย่างได้โดยไม่ต้องเปลี่ยน flag

ข้อจำกัดเก่าแก่ของ JavaScript Date

  • ตอนที่ JavaScript ถูกสร้างขึ้นในปี 1995 อ็อบเจ็กต์ Date ได้คัดลอกการใช้งาน java.util.Date รุ่นแรกของ Java มา และแม้ Java จะเปลี่ยนแทนที่สิ่งนี้ในปี 1997 แต่ JavaScript ยังคงใช้ API เดิมมาเกือบ 30 ปี
  • ปัญหาใหญ่ที่สุดคือ การรองรับเขตเวลาที่ไม่เพียงพอ และพฤติกรรมการ parse ที่ไม่เสถียร
    • รองรับเฉพาะเวลาท้องถิ่นของผู้ใช้และ UTC
    • ตัว Date เองเป็น mutable จึงอาจสร้างบั๊กที่ติดตามได้ยาก
    • การคำนวณที่ข้าม Daylight Saving Time (DST) และการเปลี่ยนแปลงปฏิทินในอดีตก็จัดการได้ยาก
  • ด้วยข้อจำกัดเหล่านี้ นักพัฒนาจำนวนมากจึงพึ่งพาไลบรารีเฉพาะทางอย่าง Moment.js หรือ date-fns เพื่อจัดการวันที่และเวลาในแอปพลิเคชัน

โมเดลวันที่และเวลาที่ Temporal จะเปลี่ยนแปลง

  • Temporal ถูกออกแบบให้เป็น ตัวแทนทั้งหมด ของอ็อบเจ็กต์ Date โดยมีเป้าหมายให้การจัดการวันที่และเวลาน่าเชื่อถือและคาดเดาได้มากขึ้น
  • รองรับการแสดงเขตเวลาและปฏิทิน พร้อมมีเมธอดในตัวสำหรับการแปลง การเปรียบเทียบ การคำนวณ และการจัดรูปแบบ
  • พื้นผิวของ API มีเมธอดยูทิลิตีกว่า 200 รายการ และมีการเพิ่มคำอธิบายกับตัวอย่างใน เอกสาร Temporal ของ MDN แล้ว

ประเภทหลักของ Temporal

  • Temporal แยก จุดเวลาเฉพาะตัว เวลาแบบนาฬิกาติดผนังในพื้นที่ และระยะเวลา ออกเป็นคนละ type
  • โครงสร้างหลักมีดังนี้
    • Temporal.Duration: ความต่างระหว่างสองจุดเวลา
    • Temporal.Instant: จุดเวลาเฉพาะตัวที่แสดงเป็น timestamp
    • Temporal.ZonedDateTime: วันที่และเวลาที่มีเขตเวลารวมอยู่
    • Temporal.PlainDateTime: วันที่และเวลาแบบเต็มที่ไม่มีเขตเวลา
      • Temporal.PlainDate: แสดงเฉพาะวันที่
      • Temporal.PlainYearMonth: ปีและเดือน
      • Temporal.PlainMonthDay: เดือนและวัน
      • Temporal.PlainTime: แสดงเฉพาะเวลา
    • Temporal.Now: API สำหรับดึงเวลาปัจจุบันเป็นอินสแตนซ์ของคลาสต่าง ๆ หรือในรูปแบบเฉพาะ

วิธีใช้งานผ่านตัวอย่าง

  • สามารถดึงวันที่และเวลาปัจจุบันเป็นสตริง ISO ได้ และส่ง เขตเวลา ให้กับหลายเมธอดได้
    • Temporal.Now.plainDateTimeISO() คืนค่าวันที่และเวลาปัจจุบันของเขตเวลาระบบ
    • Temporal.Now.plainDateTimeISO("America/New_York") คืนค่าวันที่และเวลาปัจจุบันของเขตเวลา New York
  • ยังจัดการปฏิทินนอกเหนือจาก Gregorian ได้ จึงสามารถสร้างวันที่ในระบบปฏิทินอย่าง Hebrew, Chinese และ Islamic ได้
    • คำนวณ Chinese New Year ถัดไปโดยใช้วันที่ 1 ของ M01 ในปฏิทิน Chinese
    • ในเอาต์พุตตัวอย่าง ณ เวลาที่เขียน Chinese New Year ถัดไปคือ 1/29/2025
  • สามารถแปลง timestamp แบบมิลลิวินาทีจาก Unix Epoch เป็นจุดเวลาด้วย Temporal.Instant.fromEpochMilliseconds() แล้วเปรียบเทียบกับ Temporal.Now.instant() เพื่อคำนวณเวลาที่เหลือได้
    • สำหรับ timestamp ตัวอย่าง 1851222399924 คำนวณเวลาจากปัจจุบันด้วย smallestUnit: "hour"
    • เอาต์พุตของ @js-temporal/polyfill คือ 31,600 hr ส่วนเอาต์พุตของ Firefox Nightly คือ PT31600H
  • toLocaleString ในการใช้งานของ Firefox ปัจจุบันยังไม่พิมพ์ สตริงที่ไวต่อ locale
    • พฤติกรรมนี้ใกล้เคียงกับการตัดสินใจด้านการออกแบบมากกว่าข้อจำกัดทางเทคนิค และตัว duration เองยังสามารถจัดรูปแบบได้
    • polyfill กับการใช้งานของ Firefox อาจมาบรรจบกันในภายหลัง
  • เมธอด compare() สามารถนำไปใช้กับการเรียงลำดับ array ได้
    • ใช้ durations.sort(Temporal.Duration.compare) แล้วจะเรียงเป็น PT1H, PT1H30M, PT1H45M, PT2H

การรองรับของเบราว์เซอร์และวิธีทดลอง

  • การรองรับ Temporal เริ่มค่อย ๆ ถูกใส่ในรุ่นทดลองของเบราว์เซอร์แล้ว และตอนนี้การใช้งานของ Firefox ดูจะสมบูรณ์ที่สุด
  • ใน Firefox มีการ build Temporal ไว้หลังการตั้งค่า javascript.options.experimental.temporal ใน เวอร์ชัน Nightly
  • issue หลักของเบราว์เซอร์สำหรับติดตามการใช้งานมีดังนี้
  • สามารถตรวจสอบสถานะความเข้ากันได้ทั้งหมดได้ที่ ส่วน Browser Compatibility ของอ็อบเจ็กต์ Temporal บน MDN
  • เอกสาร TC39 Temporal มี @js-temporal/polyfill ทำให้สามารถรันตัวอย่างในคอนโซล Developer Tools ได้จากทุกเบราว์เซอร์ โดยไม่ต้องเปลี่ยน flag หรือการตั้งค่าใด ๆ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-31
ความคิดเห็นจาก Hacker News

  • Temporal ยอดเยี่ยมมาก ใช้งานในโปรดักชันผ่าน polyfill มาพักหนึ่งแล้ว และช่วยแก้ปัญหาหลายอย่างที่เคยเจอกับ API Date() เดิม
    ให้ความรู้สึกว่าได้แรงบันดาลใจจากไลบรารีจัดการเวลาที่ดีอย่าง chrono ของ Rust และ Joda Time ของ Java แล้วนำมารวมเป็น API ที่ใช้งานสะดวก
    มันซับซ้อนขึ้นเล็กน้อย เพราะแยกเวลาแบบล้วน ๆ, จุดเวลา, และเวลาที่รวมเขตเวลาออกจากกัน แต่เวลาเองก็ซับซ้อนอยู่แล้ว ดังนั้นนักพัฒนาจึงต้องเผชิญกับความซับซ้อนนั้น
    แม้แต่งานอย่าง “เพิ่มหนึ่งวันให้ timestamp นี้” ก็ต้องตัดสินใจให้ชัดว่าทำโดยอิงเขตเวลาใด ไม่เช่นนั้นจะเหลือบั๊กจาก เวลาออมแสง การเปลี่ยนเขตเวลาของผู้ใช้ หรือความต่างของเขตเวลาบนเซิร์ฟเวอร์
    ยังช่วยแก้ความต่างในการ serialize ระหว่าง timestamp ที่มี offset คงที่ (2025-01-01T00:00+02:00) กับเขตเวลาเฉพาะ (Europe/Paris) ด้วย

    • Jiff ซึ่งเป็น crate ของ Rust ก็น่าดูเช่นกัน ได้แรงบันดาลใจจาก Temporal และมีสรุปการเปรียบเทียบกับ crate วันที่·เวลาอื่น ๆ รวมถึง chrono ไว้ด้วย: https://docs.rs/jiff/latest/jiff/_documentation/comparison/i...
      โดยส่วนตัวแล้วผมไม่คิดว่า Temporal ได้แรงบันดาลใจจาก chrono ของ Rust มากนัก น่าจะได้รับอิทธิพลจาก Joda หรือ java.time ในปัจจุบัน รวมถึงไลบรารีวันที่·เวลาฝั่ง JavaScript อย่าง date-fns หรือ Moment.js มากกว่า
    • คนที่มีอายุระดับหนึ่งเรียนรู้กันมานานแล้วว่าในสภาพแวดล้อมโปรดักชัน อย่าตั้งเวลา cron job ไว้ระหว่าง 01:00–03:00 ตามเวลาท้องถิ่น
    • พูดถูก แต่มีอุปสรรคอย่างหนึ่งคือ หลายคนไม่ชอบใช้ ชื่อเขตเวลา ที่อ้างถึงสถานที่จริง
      พวกเขาไม่อยากไปค้นว่า Europe/Paris หมายถึงพื้นที่กว้างในฝรั่งเศสหรือแค่ปารีส และรู้สึกรำคาญเหมือนกำลังบอกว่าตัวเองอาศัยอยู่ในปารีส
      ตอนกำหนดเวลาอีเวนต์ของชุมชนออนไลน์ เรื่องนี้เจ็บปวดมาก ผู้คนอยากใช้ offset คงที่ และโอเคกับคำอย่าง CET/CEST แต่ไม่ชอบอะไรแบบ Europe/yourexactcoordinates
      จริง ๆ แล้วก็รู้ว่าเขตเวลาส่วนใหญ่ครอบคลุมพื้นที่ค่อนข้างกว้าง แต่มีคนจำนวนมากที่ใส่ใจความเป็นส่วนตัว ทว่าก็ไม่คิดจะค้นหาความต่างระหว่าง “เวลา” กับ “เขตเวลา”
    • chrono กับ Joda Time เป็นของคนละยุคกัน ตอน Rust 1.0 ออกมา Java ก็มีแนวทางนี้ในไลบรารีมาตรฐานอย่าง java.time อยู่แล้ว และไม่จำเป็นต้องใช้ไลบรารี third-party สำหรับงานนี้
    • อยากรู้รายละเอียดเพิ่มเติมว่าความต่างในการ serialize ระหว่าง timestamp แบบ offset คงที่กับ timestamp แบบเขตเวลาเฉพาะเป็นปัญหาอย่างไร

  • ใช้เวลาพอสมควรกว่าจะหาเจอในเอกสารว่า Temporal.ZonedDateTime.prototype.withTimeZone() ใช้แปลงจากเขตเวลาหนึ่งไปยังอีกเขตเวลาหนึ่งได้: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    ถ้านำค่าที่สร้างด้วย Temporal.ZonedDateTime.from("2021-08-01T12:00[America/New_York]") ไปใส่ใน withTimeZone("Europe/Paris") จะได้ 2021-08-01T18:00:00+02:00[Europe/Paris]
    การแปลงเขตเวลาและการจัดการช่วงเวลาเป็นฟีเจอร์หลักที่ไลบรารีจำเป็นต้องรองรับ และดีที่ Temporal จัดการได้ทั้งสองอย่าง อย่างไรก็ตาม ดูเหมือนว่า Temporal.Duration จะไม่มีฟังก์ชัน format แบบกำหนดเองเพื่อสร้างผลลัพธ์อย่าง 1h03m เช่น duration.format('H\hmm\m')

    • ข้อเสนอ DurationFormatter ช่วยให้ควบคุมได้ว่าจะฟอร์แมตหน่วยใด และใช้ระดับการย่อแบบไหน เช่น 1 yr, 3 hours, 3m: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      เคยมีการ implement บางส่วนไว้ในไลบรารี icu4x

  • ตอนนี้ใน TC39 มีข้อเสนอหลายอย่างที่กำลังสุกงอม และ Temporal ก็เป็นหนึ่งในสิ่งที่อยากให้เปิดตัวเร็ว ๆ
    เข้าใจดีว่าการที่เบราว์เซอร์หลัก ๆ จะรองรับฟีเจอร์ใหม่ได้นั้นต้องอาศัยแรงพัฒนาจากวิศวกรของ v8, JSC และ SpiderMonkey จึงรู้สึกขอบคุณคนที่ทำให้เกิดความคืบหน้าจริง ๆ
    ในฐานะคนใจร้อน ก็อยากเชียร์ว่า “Records กับ Tuples ก็รีบทำให้หน่อย! สงครามไวยากรณ์ Pipe ข้ามไปก็ได้!”

    • Records และ Tuples ดูเหมือนมีโอกาสน้อยที่จะออกมา หรืออย่างน้อยก็มีโอกาสน้อยมากที่จะออกมาพร้อม semantics ของความเท่ากันแบบที่ผู้คนต้องการ
      เท่าที่เข้าใจ ผู้ผลิตเบราว์เซอร์คัดค้านค่อนข้างหนักอยู่แล้วกับการเพิ่ม primitive type ใหม่ในเวลานี้ ส่วนความยากที่ว่าความเท่ากันควรทำงานอย่างไร มีอธิบายไว้ในเธรดนี้: https://github.com/tc39/proposal-record-tuple/issues/387
      ตอนแรกไม่ได้คาดว่า BigInt จะถูกใช้เยอะขนาดนี้ แต่ในความเป็นจริงก็ยังเจอสถานการณ์ที่ต้องการคอลเลกชันที่มี structural equality อยู่เรื่อย ๆ เลยรู้สึกเสียดาย
      เข้าใจว่าการคัดค้านการเพิ่ม primitive type ใหม่ส่งผลถึง pattern matching ด้วย แต่ไม่ค่อยรู้เหตุผล และติดตามข้อเสนอนั้นน้อยกว่า
    • การที่ Temporal กำลังมาถือเป็นเรื่องดี และคงมีฟีเจอร์ดี ๆ อื่นอีกมาก แต่สำหรับข้อเสนอเฉพาะที่พูดถึงนั้นมองโลกในแง่ดีได้ยาก
      Pipeline, pattern matching และ Records+Tuples ล้วนถูกทำงานมานานกว่า 4 ปีแล้ว และยังค้างอยู่แค่ stage 1–2 ในช่วง 1 ปีที่ผ่านมาแทบไม่เห็นความคืบหน้าที่มีนัยสำคัญ ยกเว้น pattern matching อยู่บ้าง
      ตาม issue ใน repository ของ Records และ Tuples มีแรงต้านเรื่อง value semantics หรือก็คือ === จะทำงานได้หรือไม่ ถ้าตัด value semantics ออก ประโยชน์ของข้อเสนอก็ลดลงอย่างมาก
      กว่าจะไปถึง stage 3 คงต้องใช้เวลาอย่างน้อยอีก 1–2 ปี หรืออาจไปไม่ถึงเลยก็ได้ อย่างน้อยฟังก์ชันจัดกลุ่ม array ก็มีแล้ว
    • สิ่งที่อยากได้คือ pattern matching: https://tc39.es/proposal-pattern-matching/
      ยังอยู่แค่ stage 1 เลยน่าเศร้าที่น่าจะต้องรออีกหลายปี
    • ถ้าพูดถึง Records ก็สงสัยว่า Dictionary เคยเป็นข้อเสนอของ ECMA5 หรือเป็นฟีเจอร์เฉพาะตัวของ AS3 กันแน่
      Dictionary ของ AS3 เป็นชนิดที่ใช้ object reference, string และ number เป็นคีย์ที่ไม่ซ้ำกันได้ และผูกค่าชนิดใดก็ได้เข้าไปได้ Garbage collection ก็จัดการให้ไม่เป็น weak reference ตราบเท่าที่ตัว dictionary object ยังมีชีวิตอยู่
      ให้นึกถึง Set ของ JavaScript แต่เป็นรูปแบบที่ใช้คีย์ชนิดใดก็ได้ตามที่กำหนดอย่าง strongly typed และโยน error ตั้งแต่ compile time คิดถึงภาษานั้นจริง ๆ
    • ไม่ใช่ปัญหาเฉพาะผู้สร้างเบราว์เซอร์หลักเท่านั้น ช่วงที่ ES6 กำลังจะออก เคยทำ inference engine สำหรับ JavaScript อยู่ และรองรับ ES5 ได้ค่อนข้างดี แต่พออัปเดตไวยากรณ์ถาโถมเข้ามาก็ต้องยอมแพ้
      อัปเดตเหล่านั้นแทบจะทำลาย ecosystem ของ JavaScript ไปแล้ว และตอนนี้รู้สึกเหมือนเหลือแต่ภาษาที่ compile เป็น JS คนที่ยังเขียน vanilla JS อยู่ก็เหมือนคนที่สร้างแอปด้วย assembly

  • สงสัยว่าข้อมูลของแต่ละ timezone ใน Temporal จะถูกทำให้ทันสมัยอยู่เสมอได้อย่างไร
    สงสัยว่าโครงสร้างเป็นแบบที่ TC39 อัปเดตข้อมูลไว้ที่ไหนสักแห่ง แล้วแต่ละเบราว์เซอร์คัดลอกข้อมูลนั้นเข้าไปภายในและออกเวอร์ชันใหม่หรือไม่ และถ้าผู้ใช้ยังไม่ได้อัปเดตเป็นเบราว์เซอร์ที่มีข้อมูลใหม่ ผู้ใช้จะเห็นเวลาผิดบนเว็บไซต์ของเราหรือเปล่า
    ตัวอย่างเช่น เม็กซิโกยกเลิก เวลาออมแสง ในปี 2022: https://en.wikipedia.org/wiki/Time_in_Mexico
    ไลบรารี third-party อย่าง pytz หรือ moment-timezone แค่อัปเดตไลบรารีฝั่งเซิร์ฟเวอร์ก็พอ และถ้าจัดการใน standard library ก็อัปเวอร์ชันภาษาได้ แต่ไม่แน่ใจว่า Temporal กับเบราว์เซอร์ของผู้เข้าชมจะเป็นอย่างไร

    • ถ้าอ่าน “Time Zones and Resolving Ambiguity” ในเอกสารข้อเสนอ จะบอกแค่ว่าใช้ IANA timezone database แต่ไม่ได้ระบุว่าอัปเดตเมื่อไร: https://tc39.es/proposal-temporal/docs/timezone.html
      คอมพิวเตอร์ของผู้ใช้น่าจะเข้าถึง database นี้ได้และจัดการอัปเดตได้ แต่ก็ไม่แน่ใจ เบราว์เซอร์อาจดาวน์โหลดและดูแล database นี้เองต่างหาก หรืออาจขึ้นอยู่กับ implementation
      database ที่เกี่ยวข้อง: https://en.wikipedia.org/wiki/Tz_database
    • เพราะเป็นฟีเจอร์ที่ฝังมากับเบราว์เซอร์ ก็น่าจะอัปเดตตอน อัปเดตเบราว์เซอร์ ผู้ผลิตเบราว์เซอร์ทำงานมาเยอะเพื่อให้การอัปเดตรวดเร็ว และบนคอมพิวเตอร์ของผู้ใช้ทั่วไป เบราว์เซอร์น่าจะเป็นซอฟต์แวร์ที่ถูกทำให้ทันสมัยที่สุด
    • เบราว์เซอร์ต้องทำให้ locale ทันสมัยอยู่แล้วเพราะ helper ของ Intl ดังนั้นถ้าไปสำรวจฝั่งนั้นก็น่าจะได้คำตอบคล้ายกัน
    • ระบบตระกูล Unix เช่น Linux distribution, macOS, Android มีสำเนา IANA Time Zone Database ระดับระบบอยู่แล้ว ไม่แน่ใจว่าเบราว์เซอร์ใช้ของระบบหรือพกสำเนาของตัวเองมา แต่ Temporal ใช้ IANA tzdb แน่นอน
      ถ้าผู้ใช้ไม่ได้อัปเดตเบราว์เซอร์หรือระบบให้สะท้อนข้อมูล timezone ใหม่ ก็โดยรวมแล้วดูจะถูกต้องที่อาจเห็นเวลาผิดได้ แต่สิ่งนี้ก็ไม่ได้ต่างจากแนวปฏิบัติทั่วไปในปัจจุบันมากนัก
      ทางเลือกคือให้ทุกแอปพลิเคชันพก tzdb ของตัวเอง ซึ่งบางแอปก็ทำแบบนั้นและมีกรณีที่สมเหตุสมผล แต่โดยทั่วไปแล้วเป็นการสิ้นเปลือง เพิ่มความไม่สอดคล้องกันระหว่างแอปพลิเคชัน และวงรอบการอัปเดตก็มีแนวโน้มจะช้ากว่า
    • คงขึ้นอยู่กับ implementation และระบบ สุดท้าย implementation จะต้องนิยาม timezone provider และสิ่งนี้น่าจะถูกจัดให้ผ่าน host/system hook ที่ engine implementation ส่งให้ Temporal

  • ต้องเพิ่มอีเวนต์สำหรับตรวจจับเมื่อมีคนเปลี่ยนเขตเวลา
    ในรายการ “ความเชื่อผิด ๆ ที่โปรแกรมเมอร์มีเกี่ยวกับเวลา” น่าจะเพิ่มข้อว่า “โปรแกรมเมอร์เชื่อว่าเขตเวลาจะคงที่ระหว่างการใช้งาน” ได้ด้วย ในความเป็นจริงมีผู้คนนับล้านเดินทางข้ามเขตเวลาทุกวัน

    • อีเวนต์แบบนั้นน่าจะถูกใช้เป็นจุดข้อมูลอีกจุดหนึ่งสำหรับ การติดตามด้วยลายนิ้วมือดิจิทัล และคาดเดาตำแหน่งของผู้ใช้
    • ไม่ค่อยแน่ใจว่าอีเวนต์นี้จะเอาไปใช้ทำอะไร เว็บแอปพลิเคชันส่วนใหญ่ที่พึ่งพาเวลาอยู่บ้าง เมื่อคิดถึงจำนวนผู้ใช้ที่ได้รับผลกระทบแล้ว ก็ยังน่าสงสัยว่ามีค่าพอให้ต้องฟังอีเวนต์นี้โดยตรงและตอบสนองหรือไม่
      แน่นอนว่าอาจมีประโยชน์สำหรับไลบรารี
    • เขตเวลาของไคลเอนต์ควรสำคัญต่อไคลเอนต์เท่านั้น นอกจากจุดประสงค์ด้านความสะดวกในการแสดง timestamp เป็นเวลาท้องถิ่นของผู้ใช้แล้ว ก็ไม่มีเงื่อนไขใดที่นาฬิกาฝั่งไคลเอนต์จะสำคัญขึ้นมา ไม่มีเหตุผลให้ต้องสนใจแม้ผู้ใช้จะเปลี่ยนเขตเวลา
    • การติดตามการเปลี่ยนเขตเวลาต้องมีสถานะ ดังนั้นน่าจะเหมาะกว่าที่นักพัฒนาจะนิยามเองว่าจะติดตามและตอบสนองอย่างไร อาจไม่อยากให้ Temporal มีความเห็นกำหนดวิธีจัดการเรื่องนี้
    • ถ้าอยู่บนเครื่องบินหรือ ISS ก็อาจอยู่ในสถานะที่ไม่มีเขตเวลาเลยก็ได้

  • เสียดายมากที่ .Now ไม่ใช่การเรียกฟังก์ชัน ไม่ควรเป็นพร็อพเพอร์ตี
    ถ้าประเมิน .Now หลายครั้งในลูป ค่าอาจต่างกันทุกครั้ง ซึ่งเป็นสิ่งที่ไม่คาดคิด
    C# ก็เลือกแบบเดียวกัน และไม่ควรทำแบบนั้น: https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...

    • น่าจะเข้าใจผิดนะ Now เป็น เนมสเปซ ของฟังก์ชันที่ดึงค่าจริง ๆ เช่น Now.instant() อะไรแบบนั้น

  • ชอบข้อเสนอ Temporal มากจริง ๆ แต่มีเรื่องหนึ่งที่ติดใจ คือการเปรียบเทียบพึ่งพา ความเท่ากันของการอ้างอิง
    กล่าวคือ Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01')
    มันไม่ได้แย่โดยตัวมันเอง แต่แทบจะตัดความสามารถในการใช้ออบเจ็กต์เหล่านี้เป็นคีย์ของ Map หรือรวบรวมไว้ใน Set ไปเลย เข้าใจว่าทำไมถึงตัดสินใจแบบนั้น แต่ก็เสียดายที่ทำไม่ได้
    สักวันถ้า Records และ Tuples ออกมาจริง ๆ อาจมีเวอร์ชันที่อิงกับสิ่งนั้นก็ได้

    • ในบรรดา non-primitive type ของ JavaScript มีอะไรที่ == ให้ความเท่ากันแบบไม่ใช่การอ้างอิงบ้างไหม?
    • แล้วแต่สถานการณ์ ดูเหมือนจะใช้ .epochMilliseconds เป็นคีย์หรือสมาชิกของ Map/Set ได้ แต่ถ้าต้องเก็บข้อมูลเขตเวลาไว้ใน Map หรือจำเป็นต้องทำ operation เพิ่มเติมกับ Instant ก็ต้องเก็บ Instant เดิมไว้ฝั่ง value
      ในกรณีของ Set สามารถใช้แบบ Map{v.epochMilliseconds:v} เพื่อคง Instant ไว้ได้
      ไม่ได้ยอดเยี่ยม แต่เรื่องนี้ควรโทษ JavaScript เอง มากกว่า Temporal จะให้ runtime จัดการก็ได้ แต่ถ้าอย่างนั้น polyfill ก็จะล้มเหลว
    • ต่อให้ทำได้ การใช้ค่าแบบนี้ใน Map/Set ก็คล้ายกับการใช้เลข floating point ใน Map/Set ซึ่งโดยทั่วไปเป็นไอเดียที่ไม่ดี
    • เป็นเพราะใน JavaScript มันเป็นไปไม่ได้ไม่ใช่เหรอ? เว้นแต่จะใช้แฮ็กประหลาด ๆ แบบ constant string pool ของ Java ที่ทำให้ออบเจ็กต์ทุกตัวที่ใช้กลายเป็น reference ไปยังค่าในพูลออบเจ็กต์ทั้งหมด
    • ใช้ String() หรือ '2020-01-01' ไปเลยไม่ได้เหรอ?

  • การมี ฟังก์ชันเปรียบเทียบ ที่ทำงานร่วมกับ API เดิมได้เป็นการออกแบบที่แข็งแรงมาก ถึงขั้นควรกำหนดเป็นเงื่อนไขที่ต้องอ่านก่อนเพิ่ม type ใหม่เลยก็ได้
    เช่น ส่ง Temporal.Duration.compare ให้ sort ก็จะจัดเรียงได้เป็น PT1H, PT1H30M, PT1H45M, PT2H ขอปรบมือให้ผู้ออกแบบ

  • เข้าใจว่าชื่อ Temporal ตั้งใจหลีกเลี่ยงการชนกับออบเจ็กต์เวลาแบบทั่วไปอย่าง Moment, Datetime แต่ชื่อนี้ไม่ค่อยดี
    ตอนเห็นครั้งแรกนึกว่าเป็นอะไรทำนอง การควบคุม garbage collection

    • temporal มีความหมายว่าเกี่ยวกับเวลาเมื่อเทียบกับความเป็นนิรันดร์, เกี่ยวกับ tense หรือการแบ่งเวลาในไวยากรณ์, หรือเกี่ยวกับเวลาเมื่อแยกจากพื้นที่: https://www.merriam-webster.com/dictionary/temporal
      ฟังดูเป็นชื่อที่โอเค
    • นึกว่าเป็น Temporal workflow engine ในเบราว์เซอร์
    • ถึงจะเป็นการถกเรื่องสีโรงเก็บจักรยานกับการตัดสินใจที่ทำไปแล้ว แต่เห็นด้วยว่ามันเป็นชื่อที่แย่มากจริง ๆ
      อย่างแรก Temporal เป็นคำคุณศัพท์ ไม่ใช่คำนาม ถึงจะเกี่ยวกับเวลาแต่ก็ไม่ได้ตรงกับสัญชาตญาณนัก
      ที่สำคัญกว่านั้นคือ ถ้าเลือกชื่อแปลก ๆ เพื่อลดโอกาสชนกับโค้ดเก่า ภาษาโดยรวมก็จะยิ่งทึบเข้าใจยากขึ้นเมื่อเวลาผ่านไป
      ตอนเพิ่ม Promise กับ Generator ก็มีไลบรารีจำนวนมากที่ใช้ชื่อออบเจ็กต์เหล่านั้นอยู่แล้ว ต่างจาก reserved word ตรงที่ built-in object สามารถถูกเขียนทับได้ จึงไม่ได้เป็นปัญหาใหญ่
      ผมคิดว่าคณะกรรมการมาตรฐานควรยืนหยัดใช้ Time เพื่อสุขภาพระยะยาวของภาษา
      แน่นอนว่าการถกเถียงนี้ผ่านไปแล้ว และผู้ผลิตเบราว์เซอร์กับผู้พัฒนา JS engine ก็คงตกลงกันแล้ว
    • ผมก็คิดว่าเป็นชื่อที่แย่มากเหมือนกัน ใช้ DateV2 ยังดีกว่า
      เข้าใจว่าต้องมี backward compatibility แต่ Temporal ฟังแล้วไม่ดีเลย DateTime ก็ไม่ใช่ชื่อที่มีอยู่ในมาตรฐาน JS อยู่แล้ว ไม่รู้ทำไมถึงไม่ใช้ชื่อนั้น จนกว่าจะถึงตอนนั้นคงตั้ง const DateTime = Temporal ไว้ก่อน

  • บทความที่เกี่ยวข้อง:
    JavaScript Temporal Is Coming - https://news.ycombinator.com/item?id=42809834 - มกราคม 2025, 18 ความคิดเห็น
    Mozilla: Temporal (Limited Availability) - https://news.ycombinator.com/item?id=42776548 - มกราคม 2025, 1 ความคิดเห็น
    Is It Time for the JavaScript Temporal API? - https://news.ycombinator.com/item?id=29712118 - ธันวาคม 2021, 100 ความคิดเห็น
    Temporal: Getting started with JavaScript's new date time API - https://news.ycombinator.com/item?id=27661667 - มิถุนายน 2021, 194 ความคิดเห็น
    JavaScript Temporal - https://news.ycombinator.com/item?id=27395236 - มิถุนายน 2021, 1 ความคิดเห็น
    JavaScript Proposal Temporal for Dates is now stage 3 - https://news.ycombinator.com/item?id=26432346 - มีนาคม 2021, 1 ความคิดเห็น

    • รู้สึกขอบคุณที่ช่วงนี้ Web API ดีขึ้นมากจริง ๆ แต่ก็ยังน่าเสียดายที่โพสต์แรกของหัวข้อนี้ถูกส่งมาตั้งแต่มีนาคม 2021 ซึ่งเกือบ 4 ปีก่อน
      คำพูดที่ว่าเรือลำใหญ่เปลี่ยนทิศช้านี่ตรงมาก