จำได้ว่าย้อนกลับไปในปี 1999 เมื่อ - ในหมู่ Spice Mania และการสะสมทารก Beanie ด้วยเหตุผลบางอย่าง - ทุกคนต่างก็ประหลาดใจเกี่ยวกับ Millennium Bug?
ความกลัวคือเมื่อ '99 คลิกไปที่ '00 คอมพิวเตอร์จะไม่สามารถแยกวิเคราะห์ได้ว่าศตวรรษมีการเปลี่ยนแปลง วันที่จะถูกรีเซ็ตเป็นปี 1900 และระบบพึ่งพาคอมพิวเตอร์ทั่วโลกจะชนและเผาไหม้ ผลลัพธ์? อะไรก็ได้จาก“ ไม่กี่ความผิดพลาดที่น่าขบขันบนปฏิทินอิเล็กทรอนิกส์" ถึง "การล่มสลายของอารยธรรมตามตัวอักษรตามที่เรารู้” ขึ้นอยู่กับว่าคุณถามใคร
ในท้ายที่สุดแน่นอนปีใหม่จบลงด้วยความพยายามอย่างกว้างขวางและร่วมกันเบื้องหลังเพื่อหลีกเลี่ยงภัยพิบัติ และนั่นก็ใช่มั้ย การแล่นเรือใบราบรื่นตั้งแต่นั้นมา?
เดี๋ยวก่อน - มีภาคต่อ-
19 มกราคม 2038: วันนั้นสิ้นสุดลง อย่างน้อยถ้าคุณเป็นคอมพิวเตอร์ที่ใช้เวลา UNIX 32 บิต-ซึ่งเกือบทั้งหมดทำ
“ จำนวนเต็ม 32 บิตที่ลงนามสามารถเก็บหมายเลขจาก –2147483648 ถึง 2147483647”ตูเนียมบริษัท การจัดการความปลอดภัยทางไซเบอร์และระบบมีสำนักงานใหญ่ในเคิร์กแลนด์วอชิงตัน “ นี่หมายถึงการประทับเวลาสูงสุดที่ระบบเหล่านี้สามารถจัดการได้คือ 2147483647 ซึ่งสอดคล้องกับวันที่ 19 มกราคม 2038 เวลา 03:14:07 UTC”
ตัวเลขเหล่านั้นไม่ได้สุ่ม-โดยพลการเป็น 2,147,483,648 อาจดูเหมือนดวงตาของมนุษย์สำหรับคอมพิวเตอร์ที่ทำงานในฐาน 2 มันเป็นเหตุการณ์สำคัญครั้งใหญ่: เมื่อนาฬิกากระทบ 100,000,000,000,000,000,000,000,000,000,000,000,000 สำหรับระบบ 32 บิตนั่นเป็นตัวเลขจำนวนมากเกินไปที่จะถือ-ดังนั้นตัวนับจึงทำสิ่งเดียวที่มีอยู่และไปตลอดทางจนถึงจุดเริ่มต้นอีกครั้ง
“ การประทับเวลาจะล้นและกลายเป็นจำนวนลบซึ่งจะทำให้วันที่และเวลาผิด” Tanium อธิบาย “ ตัวอย่างเช่นการประทับเวลาสำหรับ [03:14:08 UTC] 20 มกราคม 2038 ในเวลา UNIX คือ 2147483648 เนื่องจากนี่ไม่ใช่การประทับเวลาที่ถูกต้องโดยใช้รูปแบบ UNIX มันจะล้นและกลายเป็น –2147483648 ซึ่งสอดคล้องกับวันที่ 13 ธันวาคม 1901 นี่คือข้อผิดพลาดปี 2038”
เราควรกังวลหรือไม่?
หลังจาก Hullabaloo ทั้งหมดเกี่ยวกับปัญหา Y2K คุณหวังว่าเราจะได้เรียนรู้บทเรียนของเราเมื่อต้องเตรียมการ ท้ายที่สุดเรารู้เกี่ยวกับข้อผิดพลาด 2038 มาตั้งแต่อย่างน้อยปี 2549 เมื่อปัญหาที่คล้ายกันกระทบซอฟต์แวร์ที่สนับสนุนเว็บเซิร์ฟเวอร์ของ AOL - แน่นอนว่า 32 ปีมีเวลามากพอที่จะหาวิธีแก้ไขได้หรือไม่?
ในความเป็นจริงมีปัญหาเรื่องง่ายสำหรับปัญหา 2038 และมันจ้องมองเราในหน้า:“ ทางออกคือการเปลี่ยนเป็นการสนับสนุนเวลา 64 บิต” Paul Budde ซีอีโอของ บริษัท ที่ปรึกษาอิสระ Paul Budde Consulting กล่าวออสเตรเลียอิสระย้อนกลับไปในปี 2022“ ด้วย 64 บิตมีพื้นที่มากพอที่จะเก็บค่าเวลาที่ผ่านมาในอนาคตที่คาดการณ์ได้แม้ว่าจะใช้ค่าเวลาความละเอียดสูง (นาโนวินาที)”
หกสิบสี่อาจดูไม่ใหญ่กว่า 32-แต่เมื่อเราจัดการกับเลขชี้กำลังมันเป็นความแตกต่างระหว่าง“ 13 ปี” และ“ ประมาณ 21 เท่าของอายุของจักรวาล” การอัพเกรดเป็นระบบจัดเก็บข้อมูลขนาดใหญ่นั้นจะยุติธรรมที่จะพูดว่าถ่อปัญหาจนถึงถนนที่มันอาจได้รับการแก้ไขทั้งหมด ดังนั้นเราได้สร้างสวิตช์ en masse หรือไม่?
อืม…ไม่ “ ฐานข้อมูลหลายประเภทรวมถึงฐานข้อมูลเชิงสัมพันธ์และ NOSQL” ยังคงพึ่งพาเวลา 32 บิต Tanium ชี้ให้เห็นเช่นเดียวกับโปรแกรมใด ๆ ที่เขียนในภาษาที่ใช้ C ตาม C เช่น C ++ และ PHP อุปกรณ์ที่ใช้งาน Windows, Linux, Android หรือ iOS อาจมีความเสี่ยงพวกเขาทราบเช่นเดียวกับ "อุปกรณ์การแพทย์ระบบควบคุมอุตสาหกรรมสำหรับสิ่งอำนวยความสะดวกเช่นสถานีพลังงานระบบการขนส่งรถยนต์ที่มีระบบคอมพิวเตอร์ออนบอร์ดที่ตรวจสอบการควบคุมเสถียรภาพทางอิเล็กทรอนิกส์
โดยรวมแล้วมันมีศักยภาพที่จะเป็นอย่างที่สุดก่อกวน แล้วเราพร้อมแล้ว?
เราพร้อมสำหรับข้อผิดพลาด 2038 หรือไม่?
เป็นการยากที่จะบอกว่าเราพร้อมสำหรับปี 2038-เมื่อระบบปฏิบัติการใหม่มีการเปิดตัวหลายคนได้รับเวลาจำนวนเต็ม 64 บิตเป็นมาตรฐานในวันนี้ แต่ปัญหาที่ใหญ่กว่านั้นคือระบบที่มีอยู่แล้ว: การเปลี่ยนจาก 32-64 บิตคือสำหรับระบบปฏิบัติการที่ใช้แหล่งกำเนิด“ ไม่มีที่ไหนใกล้เล็กน้อย” MichałGórnyนักพัฒนาสำหรับ Linux Distribution Gentoo เขียนไว้ใน A A2024 บล็อกโพสต์ในหัวข้อ
“ เหนือสิ่งอื่นใดเรากำลังพูดถึงการเปลี่ยนแปลง ABI ที่แตกหัก มันเป็นสิ่งที่ไม่มีอะไรเลย” เขาเขียน “ หากไลบรารีใช้ TIME_T ใน API ทุกอย่างที่เชื่อมโยงกับมันจำเป็นต้องใช้ความกว้างประเภทเดียวกัน […] การผสม TIME32 และ TIME64 โปรแกรมและห้องสมุดสามารถนำไปสู่ข้อบกพร่องรันไทม์ที่น่ากลัว”
โดยพื้นฐานแล้วการเปลี่ยนจากการประทับเวลา 32 บิตเป็น 64 บิตจะทำให้โปรแกรมที่มีอยู่แล้วจำนวนมากที่ต้องดิ้นรนเพื่อทำความเข้าใจระบบใหม่ มันจะเป็นเหมือนถ้าคุณถูกส่งกลับไปยังประเทศอังกฤษในยุคกลางและต้องการสื่อสารกับคนในท้องถิ่น: ในทางเทคนิคคุณจะพูดภาษาเดียวกัน แต่จริงหรือ? คุณจะไม่โดยสิ้นเชิงรู้ว่าเกิดอะไรขึ้น ณ จุดใด ๆ
และนั่นเป็นเพียงจุดเริ่มต้น เรามี - และยังมี - มีเวลามากในการเตรียมตัวสำหรับปัญหา 2038 และเมื่อมันกระทบ "ระบบคอมพิวเตอร์ปัจจุบันทั้งหมดจะได้รับการอัพเกรดได้ดีก่อนเวลานั้น" Budde ทำนาย “ อย่างไรก็ตาม […] ปัญหาเหล่านี้ส่วนใหญ่จะอยู่ในโปรแกรมเก่า ๆ ที่ไม่มีใครจำได้ว่าจะอัปเดตและทดสอบ” เขาเตือน -“ มันไม่ใช่สิ่งที่วิศวกรคอมพิวเตอร์ต้องการออกไปในนาทีสุดท้ายเช่นเดียวกับปัญหา Y2K”
แม้ว่าจะพบและอัพเกรดระบบที่มีเวลา 32 บิตทุกครั้ง แต่ผลกระทบระลอกคลื่นจากการเปลี่ยนแปลงขายส่งดังกล่าว“ จะต้องแมปก่อนแล้วจึงทำการวิจัยอย่างละเอียดเพื่อหาวิธีแก้ปัญหาที่เหมาะสมซึ่งป้องกันผลข้างเคียงที่ไม่พึงประสงค์” Budde เตือน “ และในทางกลับกันวิธีแก้ปัญหาเหล่านี้สามารถสร้างผลข้างเคียงของตัวเองได้”
เอ่อ…ใช่ นิ้วข้าม, เอ๊ะ, คน?
เรียนรู้จากความผิดพลาดของเรา
ฟัง: มามองโลกในแง่ดี สมมติว่าเราแก้ปัญหา 2038 อย่างสมบูรณ์และเอฟเฟกต์ระลอกคลื่นที่เกี่ยวข้องทั้งหมดและไม่มีระบบคอมพิวเตอร์ที่มีแม้แต่การ blip ที่ 03:14:08 ในวันที่ 20 มกราคม 2038 เราทุกคนสามารถถอนหายใจด้วยความโล่งอกและลืมเรื่องทั้งหมดได้หรือไม่?
เราทำได้ - แต่เราอาจไม่ควร เพียงไม่กี่ทศวรรษต่อมาเราจะต้องเผชิญกับสิ่งเดียวกันอีกครั้ง: ในวันที่ 7 กุมภาพันธ์ 2106 เวลา 06:28:15 UTC ปัญหาจะกระทบกับระบบทั้งหมดที่จัดเก็บเวลาเป็น ANไม่ได้ลงนามจำนวนเต็ม 32 บิต-นั่นคือการใช้ตัวเลขจำนวนเท่ากัน แต่ไม่ให้จำนวนใด ๆ กับตัวเลขลบ
กรอไปข้างหน้าอย่างรวดเร็วในช่วงเวลาเดียวกันอีกครั้งและ Windows กำลังเผชิญกับข้อผิดพลาดเวอร์ชันของตัวเอง:“ Windows NT ใช้จำนวนเต็ม 64 บิตเพื่อติดตามเวลา” หมายเหตุหมายเหตุHowstuffworks- “ อย่างไรก็ตามมันใช้นาโนวินาที 100 ครั้งเป็นการเพิ่มขึ้นและการเริ่มต้นของเวลาคือ 1 มกราคม 1601 ดังนั้น NT ทนทุกข์ทรมานจากปัญหาปี 2184”
อดีตที่มีปัญหา 2262 ปัญหา 2262 และแม้แต่ปัญหา 2446 ทั้งหมดที่เกี่ยวข้องกับสมมติฐานของโปรแกรมเมอร์ที่ผ่านมาว่าเราจะใช้โปรโตคอลที่คิดค้นขึ้นมานานแค่ไหนในช่วงกลางศตวรรษที่ 20 เราจะบอกว่ามันเป็นสายตาสั้นของพวกเขา-แต่มาดูกันเถอะ: เร็ว ๆ นี้เราจะมีเพื่อจัดการกับในทุกกรณี
