รูปแบบที่ต้องการของชื่อไฟล์ซึ่งรวมถึงการประทับเวลา

ในขณะที่เราทุกคนรู้ว่า "unix" สามารถมีอะไรในไฟล์ยกเว้น '/' และ '\ 0', sysadmins อย่างไรก็ตามมักจะมีการตั้งค่าที่มีขนาดเล็กมากส่วนใหญ่เนื่องจากไม่มีช่องว่างที่ชอบเป็นอินพุต ... และสิ่งต่าง ๆ ที่มี ความหมายพิเศษสำหรับ ':' และ '@' ในหมู่คนอื่น ๆ

เมื่อเร็ว ๆ นี้ฉันเคยเห็นกรณีอื่นที่ใช้การประทับเวลาในชื่อไฟล์และหลังจากเล่นด้วยรูปแบบที่แตกต่างกันเล็กน้อยเพื่อให้ "ดีขึ้น" ฉันคิดว่าฉันพยายามหา "แนวปฏิบัติที่ดีที่สุด" ไม่พบสิ่งที่ฉันคิด ฉันแค่ถามที่นี่และดูว่าผู้คนคิดอย่างไร

โซลูชัน "ทั่วไป" ที่เป็นไปได้ (p = คำนำหน้าและ s = คำต่อท้าย):

1. syslog / logrotate / DNS เช่นเดียวกับรูปแบบ:

   p-%Y%m%d-suffix = prefix-20110719-s
   p-%Y%m%d%H%M-suffix = prefix-201107191732-s
   p-%Y%m%d%H%M%S-suffix = prefix-20110719173216-s
   

   ข้อดี:

   • เป็น "ทั่วไป" ดังนั้น "ดีพอ" อาจดีกว่า "ดีที่สุด"
   • ไม่มีตัวละครแปลก ๆ
   • ง่ายต่อการแยก "วันที่ / เวลาหยด" จากทุกอย่างอื่น

   ข้อเสีย:

   • รุ่นเฉพาะวันที่ไม่ใช่เรื่องง่ายที่จะอ่านและรวมถึงเวลาที่ทำให้ตาของฉันมีเลือดออกและวินาทีเช่นกันเป็นเพียง "lol"
   • ถือว่า TZ

2. รูปแบบ ISO-8601-

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%dT%H:%M%z-s = p-2011-07-19T17:32-0400-s
   p-%Y-%m-%dT%H:%M:%S%z-s = p-2011-07-19T17:32:16-0400-s
   p-%Y-%m-%dT%H:%M:%S%z-s = p-2011-07-19T23:32:16+0200-s
   

   ข้อดี:

   • ไม่มีช่องว่าง
   • พิจารณา TZ
   • คือ "ไม่เลว" ที่มนุษย์อ่าน (วันที่เท่านั้นคือโวลต์ดี)
   • สามารถสร้างได้โดย $ (date --iso = {ชั่วโมงนาทีวินาที})

   ข้อเสีย:

   • SCP / tar / ฯลฯ จะไม่ชอบอักขระ ':'
   • ใช้เวลาสักครู่เพื่อให้คน "ปกติ" เห็น WTF ที่ 'T' มีไว้สำหรับสิ่งที่ท้ายที่สุดคือ :)
   • อักขระ '-' มากมาย

3. รูปแบบ rfc-3339

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%d %H:%M%:z-s = p-2011-07-19 17:32-04:00-s
   p-%Y-%m-%d %H:%M:%S%:z-s = p-2011-07-19 17:32:16-04:00-s
   p-%Y-%m-%d %H:%M:%S%:z-s = p-2011-07-19 23:32:16+02:00-s
   

   ข้อดี:

   • พิจารณา TZ
   • สามารถอ่านได้ง่ายโดย "มนุษย์ทุกคน"
   • สามารถแยกความแตกต่างวันที่ / เวลาจากคำนำหน้า / คำต่อท้าย
   • บางส่วนของข้างต้นสามารถสร้างได้ด้วย $ (date --iso = {ชั่วโมงวินาที)

   ข้อเสีย:

   • มีช่องว่างในรุ่นเวลา (ซึ่งหมายความว่ารหัสทั้งหมดจะเกลียดชัง)
   • SCP / tar / ฯลฯ จะไม่ชอบอักขระ ':'

4. ฉันรักยัติภังค์:

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%d-%H-%M-s = p-2011-07-19-17-32-s
   p-%Y-%m-%d-%H-%M-%S-s = p-2011-07-19-23-32-16-s
   

   ข้อดี:

   • โดยทั่วไปเป็น syslog / nicer เล็กน้อย ตัวแปร

   ข้อเสีย:

   • อักขระ '-' มากมาย
   • ถือว่า TZ

5. ฉันรักยัติภังค์พร้อมด้วยส่วนขยาย:

   p.%Y-%m-%d.s = p.2011-07-19.s
   p.%Y-%m-%d.%H-%M.s = p.2011-07-19.17-32.s
   p.%Y-%m-%d.%H-%M-%S.s = p.2011-07-19.23-32-16.s
   

   ข้อดี:

   • โดยพื้นฐานแล้วจะแตกต่างกันเล็กน้อยกว่า "ฉันชอบยัติภังค์"
   • ไม่มีตัวละครแปลก ๆ
   • สามารถแยกความแตกต่างวันที่ / เวลาจากคำนำหน้า / คำต่อท้าย

   ข้อเสีย:

   • ใช้ '.' ที่นี่ค่อนข้างไม่ใช่แบบดั้งเดิม
   • ถือว่า TZ

... ดังนั้นทุกคนต้องการให้ความพึงพอใจและเหตุผลหรือมากกว่าหนึ่ง (เช่นไม่สนใจ TZ ถ้าเป็น 95 +% ที่จะอยู่ในพื้นที่ของเครื่องจักร แต่ไม่สนใจอะไรมาก

หรือเห็นได้ชัดว่ามีบางอย่างที่ไม่อยู่ในรายการด้านบน

1. รูปแบบ ISO 8601 ควรได้รับการปฏิบัติให้มากที่สุดเนื่องจากเป็นสิ่งที่ใกล้เคียงที่สุดที่มีมาตรฐาน
2. 'T' ไม่เพียงพอสำหรับการสะดุดเพื่อรับประกันการกำจัดมัน
3. The ': อาจเป็นฆาตกรดังนั้นควรหลีกเลี่ยง
4. ด้วยเหตุผลที่กล่าวถึงในคำตอบของผู้อื่นควรใช้ UTC (หรือเวลา Z)
5. ISO 8601 รวมถึงรูปแบบการใช้ UTC ('Z' เวลา) ซึ่งควรใช้
6. ISO 8601 มีรูปแบบที่ไม่ใช้อักขระ ':' ซึ่งควรใช้

ดังนั้น ... ตัวอย่างรูปแบบวันที่ "ดีที่สุด":

1. 20120317T1748Z

   • 100% ตามมาตรฐาน ISO 8601
   • อักขระที่เป็นตัวอักษรและตัวเลขเท่านั้น (เป็นมิตรกับระบบดูแลระบบมาก)
   • ไม่ใช่คนอ่านที่เร็วที่สุด แต่คนทั่วไปสามารถอ่านได้อย่างแน่นอน

2. 2012-03-17T1748Z

   • ส่วนวันที่เป็นไปตาม ISO 8601
   • ส่วนเวลาเป็นไปตามมาตรฐาน ISO 8601
   • การเปลี่ยนระหว่างวันที่และเวลาเป็นไปตามมาตรฐาน ISO 8601
   • ผสมรูปแบบ 'ขยาย' ของ ISO 8601 (วันที่มียัติภังค์, เวลากับโคลอน) กับรูปแบบ ISO 8601 'พื้นฐาน' (วันที่ไม่มีเครื่องหมายขีดคั่น, เวลาที่ไม่มีเครื่องหมายโคลอน) ซึ่งน่าจะไม่ถูกต้องนัก
   • เพิ่มอักขระ '-' (vs 1)
   • ง่ายกว่าสำหรับคนธรรมดาที่จะอ่าน (vs 1. )

3. 2012-03-17--1748Z

   • ส่วนวันที่เป็นไปตาม ISO 8601
   • ส่วนเวลาเป็นไปตามมาตรฐาน ISO 8601
   • การเปลี่ยนระหว่างวันที่และเวลาไม่เป็นไปตามมาตรฐาน ISO 8601
   • ผสมรูปแบบ ISO 8601 'เพิ่มเติม' กับรูปแบบ ISO 8601 'พื้นฐาน'
   • ง่ายกว่าสำหรับคนธรรมดาที่จะอ่าน (เทียบกับ 1 และ 2)
   • ไม่มีตัวละครใหม่ (vs 2)

ฉันเป็นบางส่วนถึง 1 เนื่องจากเป็น IAW ที่สมบูรณ์ตามมาตรฐาน แต่อย่างอื่นอยู่ใกล้

หมายเหตุ :: เพิ่มวินาทีตามความจำเป็นแน่นอน ... และใช่โดยมีหรือไม่มีวินาที (หรือแม้กระทั่งนาที) คือ IAW ISO 8601 ทั้งหมด :)

ฉันจะไม่รวมเขตเวลาใช้เวลาสากลเท่านั้น หากอาจมีความสับสนคุณสามารถเพิ่มคำต่อท้าย -UTC หากคุณระบุเขตเวลาใครบางคนอาจขึ้นอยู่กับมัน และจะมีกรณีขอบแปลก ๆ ที่การเปลี่ยนแปลงเวลาหรือเปลี่ยนกะเวลาเกิดความเสียหายในการประมวลผลบางอย่างหรือการประมวลผลที่แตกต่างกันในบางระบบเพราะการกำหนดค่า DST ของพวกเขาไม่ทันสมัย UTC จะเหมือนเดิมทุกที่

ฉันคิดว่ายัติภังค์ทำให้ชื่อไฟล์อ่านได้ง่ายขึ้นในแง่ที่ว่ามันง่ายต่อการมองเห็นวันที่และเวลาของข้อมูลไฟล์ หากคุณต้องการรวมความแม่นยำย่อยที่สองนั่นคือ. nnnnn

โดยส่วนตัวฉันไม่ชอบ T การใช้โคลอนในชื่อไฟล์อาจส่งผลกระทบต่อการทำงานร่วมกันกับระบบไฟล์อื่น ๆ

1. ฉันก็จะไม่รวมเขตเวลา สคริปต์ / เครื่องมือของคุณซึ่งประมวลผลบันทึกควรรู้เกี่ยวกับเรื่องนั้น นอกจากนี้เกี่ยวกับการเปลี่ยนแปลงเวลาฤดูร้อน / ฤดูหนาว - ฉันแนะนำให้เซิร์ฟเวอร์ของคุณได้รับการแก้ไขเสมอที่ UTC ตลอดเวลา ความแตกต่างอย่างฉับพลันระหว่างเขตเวลาของเซิร์ฟเวอร์ฐานและเขตเวลา (ไม่เปลี่ยนแปลง) ของฐานข้อมูลที่ทำงานอยู่อาจทำให้ปวดศีรษะ ;-)

2. เกี่ยวกับการตั้งชื่อไฟล์บันทึก - ฉันรู้ว่าหลายคนไม่ชอบ แต่ฉันชอบที่จะทำให้มันง่าย:

p-%s-type.log = p-1311116459-type.log

ข้อดี:

• ตัวหารร่วม
• ใช้งานง่ายมากในการเขียนสคริปต์เพิ่มเติม

ข้อเสีย:

• ไม่ใช่มนุษย์ที่อ่านได้

บนเครื่องที่เพื่อนร่วมงาน (ด้วยเหตุผลใดก็ตาม) จำเป็นต้องตรวจสอบบันทึกด้วยตนเองฉันไปหาตัวแปรนี้หมุนทุกวัน:

p-%Y-%m-%d-type.log = p-2011-07-20-type.log

ขอแสดงความนับถืออย่างสูง