รันแอป Windows ที่วันใดก็ได้ โดยไม่แตะนาฬิกาของระบบ

ตั้งนาฬิกาของแอปเพียงตัวเดียวให้เป็นปีหน้า หยุดมันไว้ หรือเร่งให้ช่วงทดลองใช้ 30 วันหมดลงระหว่างที่คุณชงกาแฟ ส่วนเครื่องที่เหลือยังใช้เวลาจริงตามเดิม - การล็อกอินโดเมน ใบรับรอง และโปรแกรมอื่นทุกตัวทำงานต่อไปตามปกติ

จากนั้นมันจะบอกคุณว่าการแทนที่เวลาได้ผลจริงหรือไม่

ดาวน์โหลดสำหรับ Windows ดูโค้ดบน GitHub

ฟรีและโอเพนซอร์ส GPL-3.0 พกพาหรือติดตั้ง ใช้งานโดยไม่ต้องมีสิทธิ์ผู้ดูแลระบบ ไม่เชื่อมต่ออินเทอร์เน็ตเลย

หน้าตาของเซสชัน

แอปเห็นเวลานี้

2027-12-31
23:59:50

เขตเวลาของเซสชัน -05:00

เครื่องยังเห็นเวลานี้

2026-09-04
18:12:33

เขตเวลาของโฮสต์ +02:00

ใช้งานได้ - การแทนที่เวลามาถึงโพรเซสนี้แล้ว

ช่องทางเวลาที่เฝ้าดู สูงสุด 44 ช่อง · แต่ละช่องมีจำนวนครั้งที่เรียก

แผงเซสชันของ Chrono Mock นาฬิกาของแอปแสดง 2038-01-19 03:14:14 และนาฬิกาจริงที่อยู่ข้างกันแสดง 2026-09-22 15:50:30 โดยแต่ละเรือนมีเวลาที่ผ่านไปของตัวเอง ด้านล่างเป็นความเร็วตั้งแต่ x1 ถึง x1440 พร้อมปุ่ม Freeze จากนั้นเป็นการกระโดดแบบสัมพัทธ์และการกระโดดไปยังวันที่ที่พิมพ์ และที่ท้ายหน้ามีเครื่องหมายถูกสีเขียวข้างคำว่า Works ติดกับปุ่ม Stop session สีแดง — เซสชันที่กำลังทำงาน แอปอยู่ในปี 2038 แต่เครื่องไม่ใช่ และผลสรุประบุว่าการแทนที่เวลามาถึงแอปแล้ว

ทำไมถึงมีสิ่งนี้

การทดสอบทุกอย่างที่ขึ้นกับวันที่ต้องเลื่อนเวลา และสองวิธีที่ใช้กันทั่วไปล้วนไม่ดี

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

ทางเลือกที่ 1 - เปลี่ยนนาฬิกาของระบบ

มันทำให้การล็อกอินโดเมนและ Kerberos พัง ทำให้ใบรับรอง TLS ใช้ไม่ได้จนเบราว์เซอร์หยุดทำงาน ทำให้ Windows Update สับสน และทำให้แอปอื่นทุกตัวในเครื่องบันทึกเวลาผิด ในเครื่องที่เข้าร่วมโดเมน นโยบายกลุ่มมักบล็อกการเปลี่ยนแปลงนี้หรือเปลี่ยนกลับหลังไม่กี่นาที การทดสอบจึงทำซ้ำไม่ได้ด้วยซ้ำ

ทางเลือกที่ 2 - รอ

ซึ่งก็คือไม่ทดสอบ กรณีที่ขึ้นกับวันที่จึงถูกข้ามไป และเวอร์ชันที่ “ไลเซนส์ไม่เคยหมดอายุ” ก็ไปถึงมือลูกค้า

ทำอะไรได้บ้าง

หนึ่งโพรเซสเดินทางข้ามเวลา ส่วนทุกอย่างที่เหลือในเครื่องอยู่กับที่

ช่วงเวลาใดก็ได้

วันที่และเวลาที่เจาะจง หรือเวลาแบบสัมพัทธ์ - +30 days, -1 year

เดินปกติ หยุดนิ่ง หรือเร่งความเร็ว

ความเร็วปกติ นาฬิกาที่หยุดค้างไว้ หรือตัวคูณที่เป็นจำนวนเต็ม x1440 ทำให้หนึ่งวันเหลือหนึ่งนาที

เขตเวลาของตัวเอง

ออฟเซ็ตคงที่เฉพาะโพรเซสนั้น ขณะที่เขตเวลาของระบบอยู่ที่เดิมทุกประการ

โพรเซสย่อยไปด้วยกัน

ตัวติดตั้งและตัวเปิดแอปมักสร้างโพรเซสย่อย ถ้าไม่ตามไปด้วย การทดสอบก็ครอบคลุมแค่ครึ่งหนึ่งของสิ่งที่รัน

กระโดดกลางเซสชัน

ไปข้างหน้าหรือถอยหลังก็ได้ - รวมถึงการถอยหลังที่โน้ตบุ๊กทำหลังซิงก์กับเซิร์ฟเวอร์เวลาอีกครั้ง

Electron และ Chromium ก็ได้

ผ่านกลไกอีกแบบหนึ่ง เพราะนาฬิกาของมันอยู่ในเรนเดอเรอร์แบบแซนด์บ็อกซ์ที่การฉีดเข้าไปไม่ถึง

ส่วนที่ไม่มีใครทำ

คุณจะรู้ได้อย่างไรว่าได้ผล?

กับเครื่องมืออื่นทุกตัว คุณไม่มีทางรู้ แอปเริ่มทำงาน แสดงวันที่บางอย่าง แล้วคุณก็สันนิษฐานเอาเอง แต่แอปอาจอ่านนาฬิกาผ่านช่องทางที่เครื่องมือไม่เคยดักไว้ - จากเซิร์ฟเวอร์ จากฐานข้อมูล ผ่านเลเยอร์รันไทม์ - และเมื่อนั้นคำว่า “ทดสอบผ่าน” ก็ไม่มีความหมายเลย

→ผลสรุปก่อนที่การทดสอบจริงจะเริ่ม: ใช้งานได้ / ใช้งานได้บางส่วน / ใช้งานไม่ได้
→ช่องทางเวลา 44 ช่องทางช่องใดบ้างที่ครอบคลุม และแอปสอบถามแต่ละช่องกี่ครั้ง
→ช่องทางใดที่ไม่ครอบคลุม - ระบุตรง ๆ ไม่เคยละไว้
→คำเตือนที่ระบุผลที่ตามมา: “แอปนี้อ่านเวลาจากเครือข่าย - การแทนที่ในเครื่องอาจไม่เพียงพอ”

การตรวจสอบแหล่งเวลาทำงานอย่างไร →

สองนาทีกับมัน

หน้าต่างสำหรับสำรวจ บรรทัดคำสั่งสำหรับ CI เครื่องยนต์ตัวเดียวกันอยู่เบื้องหลังทั้งสองอย่าง

# รันแอปเสมือนว่าเป็นวินาทีสุดท้ายของปี 2027
chrono run "C:\apps\test.exe" --at 2027-12-31T23:59:59

# ดูช่วงทดลองใช้ 30 วันหมดลงระหว่างชงกาแฟ: x1440 คือหนึ่งวันต่อนาที
chrono run "C:\apps\test.exe" --mode x1440

# ใช้สถานการณ์ที่ตั้งชื่อไว้แทนวันที่ และเขียนหลักฐานลงไฟล์
chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt

เครื่องคิดเลขตอบอีกครึ่งหนึ่งของการทดสอบวันที่ - ควรใช้วันที่ไหน:

$ chrono calc --preset year-2038 --zone +00:00
Chrono Mock - date calculator
  preset:   year-2038 - 2038 boundary
  explains: Does the app survive the 32-bit Unix time boundary (2038-01-19T03:14:07Z)?
  base:    2038-01-19T03:14:07
  result:  2038-01-19T03:14:07
  formats:
    ISO date      2038-01-19
    ISO datetime  2038-01-19T03:14:07+00:00
    US            01/19/2038
    PL            19.01.2038
    epoch (s)     2147483647
    epoch (ms)    2147483647000
    FILETIME      137919572470000000
    RFC 1123      Tue, 19 Jan 2038 03:14:07 GMT
  ...
  what this date lands on:
    at or past the 2038-01-19T03:14:07Z 32-bit time_t limit (Y2038)

เทียบกับสิ่งที่คุณน่าจะใช้อยู่

เหมือน RunAsDate แต่เติมส่วนที่ขาดหายไป

RunAsDate ดักฟังก์ชันนาฬิกาติดผนังห้าตัวและทำได้ดี ต่อไปนี้คือจุดที่ทั้งสองต่างกัน - และหน้าฉบับเต็มยังบอกด้วยว่า RunAsDate ยังเป็นตัวเลือกที่ดีกว่าในกรณีใด

	RunAsDate	Chrono Mock
รันแอปหนึ่งตัวที่วันที่ปลอม	ใช่	ใช่
ช่องทางเวลาที่ดัก	5	44 (เลื่อน 30 ช่อง นับอย่างเดียว 14 ช่อง)
เร่งนาฬิกา	ไม่	ใช่
เขตเวลาที่เป็นอิสระ	ไม่มีเอกสาร	ใช่
ตามโพรเซสย่อย	ไม่มีเอกสาร	ใช่
บอกว่าได้ผลหรือไม่	ไม่	ใช่ แยกตามช่องทาง
มีซอร์สโค้ด	ฟรีแวร์ ปิดซอร์ส	GPL-3.0

การเปรียบเทียบฉบับเต็ม รวมถึงจุดที่ RunAsDate ชนะ →

รับไปใช้

แตกไฟล์ที่ไหนก็ได้แล้วรัน หรือติดตั้ง .msi ที่ลงนามแล้วสำหรับทุกบัญชีบนเครื่อง การรันไม่ต้องใช้สิทธิ์ผู้ดูแลระบบ และไฟล์ zip ไม่เขียนอะไรลงรีจิสทรี

ดาวน์โหลดสำหรับ Windows ดูโค้ดบน GitHub