มีคำตอบยาวและค่อนข้างชัดเจนเกี่ยวกับความแตกต่างระหว่าง

• TIMESTAMP WITH TIME ZONE -vs-
• TIMESTAMP WITHOUT TIME ZONE

มีอยู่ในโพสต์ SOนี้ สิ่งที่ฉันต้องการทราบคือมีกรณีการใช้งานที่ถูกต้องสำหรับการใช้งานจริงTIMESTAMP WITHOUT TIME ZONEหรือควรได้รับการพิจารณาว่าเป็นรูปแบบการต่อต้าน

นี่คือที่ระบุในหลายสถานที่ แต่ฉันคิดว่ามันคุ้มค่าการกล่าวขวัญเสมอเมื่อเราเปรียบเทียบtimestamp with time zoneกับtimestamp without time zoneประเภทไม่เก็บโซนเวลาข้อมูลพร้อมกับการประทับเวลา การจัดเก็บข้อมูลทั้งหมดในเขตเวลา UTC ตามที่ระบุในเอกสารคืออะไร:timestamp WITH time zone

สำหรับการประทับเวลาพร้อมโซนเวลาค่าที่จัดเก็บภายในจะเป็น UTC (เวลาพิกัดสากลซึ่งมักรู้จักกันในชื่อเวลามาตรฐานกรีนิช, GMT) ค่าอินพุตที่มีเขตเวลาที่ระบุชัดเจนถูกแปลงเป็น UTC โดยใช้ออฟเซ็ตที่เหมาะสมสำหรับโซนเวลานั้น หากไม่มีการระบุเขตเวลาในสตริงป้อนข้อมูลจะถือว่าอยู่ในเขตเวลาที่ระบุโดยพารามิเตอร์ TimeZone ของระบบและแปลงเป็น UTC โดยใช้ออฟเซ็ตสำหรับเขตเวลา

ถือว่าใช้ได้สำหรับบางคนtimestamp WITHOUT time zoneในสถานการณ์ที่ (1) ทุกอย่างอยู่ในเขตเวลาเดียวกันหรือ (2) ชั้นแอปพลิเคชันจัดการกับเขตเวลาและเพียงเก็บทุกอย่างไว้ในเขตเวลาที่แน่นอน (ปกติคือ UTC) แต่ก็ถือว่าเป็นการต่อต้านแบบง่าย ๆ เพราะวิธีแก้ปัญหาที่ถูกต้องสำหรับ (1) คือการกำหนดค่าการตั้งค่า TimeZone เป็นหนึ่งเขตเวลาที่กำหนดสำหรับระบบและ (2) ได้รับการแก้ไขแล้วเนื่องจาก PostgreSQL เก็บทุกอย่างไว้ในเขตเวลาเดียวกัน (UTC)

timestamp WITHOUT time zoneขณะนี้มีทั้งสองลงมาที่ฉันจะมีเพียงหนึ่งเหตุผลที่ดีในการใช้งาน นั่นคือเมื่อคุณต้องการเก็บเหตุการณ์ในอนาคตและการแจ้งเตือนบางประเภทจะต้องถูกกระตุ้นเมื่อเราถึงเวลานั้น สิ่งนี้อาจเป็นสิ่งที่ดีtimestamp WITH time zoneถ้าและหากกฎที่กำหนดโดยกฎหมายของภูมิภาคเกี่ยวกับเขตเวลาไม่เปลี่ยนแปลง กฎที่พบบ่อยที่สุดที่มีการเปลี่ยนแปลงนั้นเกี่ยวกับการยอมรับหรือไม่ประหยัดเวลากลางวัน (DST)

ตัวอย่างเช่นสมมติว่าคุณอยู่ที่สมมติว่า2013-06-15(ยังไม่อยู่ใน DST) กำหนดเหตุการณ์บางอย่างให้เกิดขึ้นที่2013-01-15 10:00(ซึ่งจะเป็น DST อยู่แล้ว) และใน2013-06-15ภูมิภาคของคุณได้รับมอบหมายให้นำ DST มาใช้ แต่หลังจากนั้นรัฐบาลเปลี่ยนกฎและบอกว่าภูมิภาคของคุณจะไม่ใช้ DST อีกต่อไปและทันใดนั้นเวลาที่กำหนดของคุณจะกลายเป็น2013-01-15 11:00(แทน10:00) หากคุณใช้timestamp WITH time zoneและทำให้การกำหนดค่า TZ ของคุณเป็นปัจจุบัน แน่นอนคุณอาจสังเกตเห็นว่าเป็นไปได้ที่จะปฏิบัติต่อกรณีดังกล่าวด้วยเขตเวลาหากคุณติดตามการเปลี่ยนแปลงกฎในภูมิภาค / เขตเวลาที่คุณสนใจและปรับปรุงระเบียนที่ได้รับผลกระทบ

ควรกล่าวถึงว่าบางภูมิภาคมักจะเปลี่ยนแปลงกฎเหล่านี้ (เช่นที่บราซิลบางรัฐ - ไม่ใช่ทั้งประเทศ - มักจะเปลี่ยนแปลง) แต่ในกรณีส่วนใหญ่จะเปลี่ยนไปก่อนหน้านี้มากดังนั้นผู้ใช้ของคุณจะได้รับผลกระทบจากเหตุการณ์ที่กำหนดเท่านั้น เวลาปัจจุบัน

จากทั้งหมดที่กล่าวมาฉันมีข้อเสนอแนะอีกหนึ่งข้อเท่านั้น หากคุณมีผู้ใช้, บันทึก, timestamp with time zoneหรืออะไรที่เขตเวลาที่แตกต่างกันในการจัดเก็บเขตเวลาที่พวกเขาจะมาจากที่ไหนสักแห่งและเลือกและการใช้งาน ด้วยวิธีนี้คุณสามารถ (1) ข้ามเหตุการณ์ที่เกิดขึ้นใกล้กันเพื่อหาแหล่งที่แตกต่างกัน (เป็นอิสระจากเขตเวลาของพวกเขา) และ (2) แสดงเวลาเดิม (เวลานาฬิกา) เหตุการณ์ที่เกิดขึ้น

ใช่. TIMESTAMP WITHOUT TIME ZONEมีกรณีการใช้งานสำหรับการเป็น

• ในแอปทางธุรกิจทั่วไปประเภทนี้จะใช้สำหรับ:
  • จองนัดหมายในอนาคต
  • เป็นตัวแทนของเวลาเดียวกันของวันในเขตเวลาต่างๆเช่นเที่ยงในวันที่ 23 ในโตเกียวและในปารีส (ช่วงเวลาที่แตกต่างกันสองชั่วโมงชั่วโมงกันในเวลาเดียวกันของวัน)
• สำหรับการติดตามช่วงเวลาเฉพาะจุดบนไทม์ไลน์ที่มักจะใช้ไม่ได้ TIMESTAMP WITH TIME ZONEWITHOUT

TIMESTAMP WITHOUT TIME ZONEค่าไม่ใช่จุดบนไทม์ไลน์ไม่ใช่ช่วงเวลาจริง พวกเขาเป็นตัวแทนความคิดที่หยาบเกี่ยวกับศักยภาพช่วงเวลาที่จุดที่เป็นไปได้ในระยะเวลาตามช่วงประมาณ 26-27 ชั่วโมง (ช่วงของโซนเวลาทั่วโลกบริการ) พวกเขาไม่มีความหมายที่แท้จริงจนกว่าคุณจะใช้เขตเวลาหรือชดเชยจาก UTC

เช่นคริสต์มาส

ตัวอย่างเช่นสมมติว่าคุณต้องบันทึกวันเริ่มต้นของวันหยุด / วันศักดิ์สิทธิ์

Table: holiday_

Column: year_         Type: SMALLINT
Column: description_  Type: VARCHAR
Column: start_        Type: TIMESTAMP WITHOUT TIME ZONE

เพื่อบันทึกความจริงที่ว่าคริสมาสต์เริ่มต้นหลังเที่ยงคืนของวันที่ 25 ธันวาคมปีนี้เราต้องบอกว่า2016-12-25 00:00:00ไม่มีโซนเวลาใด ๆ ในช่วงต้นของวันซานต้าเขาไปเที่ยวโอ๊คแลนด์นิวซีแลนด์หลังเที่ยงคืนเนื่องจากเป็นหนึ่งในมิด Midnights ที่เก่าแก่ที่สุดในโลก จากนั้นเขาก็เดินทางไปทางตะวันตกเมื่อเที่ยงคืนถัดไปเกิดขึ้นในไม่ช้าก็มาถึงฟิลิปปินส์ จากนั้นกวางเรนเดียร์ก็เดินไปในทิศทางตะวันตกโดยไปถึงอินเดียในเวลาเที่ยงคืนซึ่งเกิดขึ้นหลายชั่วโมงหลังจากเที่ยงคืนโอ๊คแลนด์ ในเวลาต่อมายังคงเป็นเที่ยงคืนใน Paris FR และต่อมาเที่ยงคืนใน Montreal CA การเยี่ยมชมทั้งหมดของซานต้าเกิดขึ้นในช่วงเวลาที่แตกต่างกันคือเวลาแต่เกิดขึ้นไม่นานหลังจากเที่ยงคืนต่อเที่ยงคืนของแต่ละท้องถิ่น

ดังนั้นการบันทึก2016-12-25 00:00:00โดยไม่มีเขตเวลาใด ๆ เป็นจุดเริ่มต้นของคริสมาสต์เป็นข้อมูลและถูกต้องตามกฎหมาย แต่เพียงราง จนกว่าคุณจะพูดว่า "คริสต์มาสในโอ๊คแลนด์" หรือ "คริสต์มาสในมอนทรีออ" เราไม่มีเวลาที่เฉพาะเจาะจง หากคุณกำลังบันทึกช่วงเวลาที่เกิดขึ้นจริงในแต่ละครั้งที่เลื่อนลงคุณจะใช้TIMESTAMP WITH TIME ZONEมากกว่าWITHOUTประเภท

คล้ายกับคริสต์มาสเป็นวันส่งท้ายปีเก่า เมื่อไทม์สแควบอลลดลงใน New York , คนที่อยู่ในซีแอตเติยังคงหนาวแชมเปญของพวกเขาและการเตรียมความพร้อมของพวกเขาแตรบุคคล แต่เราจะบันทึกความคิดของช่วงเวลาปีใหม่เป็นใน2017-01-01 00:00:00 TIMESTAMP WITHOUT TIME ZONEในทางตรงกันข้ามถ้าเราต้องการบันทึกเมื่อลูกบอลตกลงในนิวยอร์กหรือเมื่อผู้คนในซีแอตเทิลเป่าเขาเขาเราจะใช้TIMESTAMP WITH TIME ZONE(ไม่ใช่WITHOUT) เพื่อบันทึกช่วงเวลาที่เกิดขึ้นจริงแต่ละสามชั่วโมงนอกเหนือจากที่อื่น

ตัวอย่าง: กะโรงงาน

อีกตัวอย่างหนึ่งอาจบันทึกนโยบายที่เกี่ยวข้องกับเวลานาฬิกาแขวนข้ามสถานที่ต่างๆ สมมติว่าเรามีโรงงานในดีทรอยต์ดึสเซลดอร์ฟและเดลี ถ้าเราบอกว่าที่ทั้งสามโรงงานเปลี่ยนครั้งแรกเริ่มต้นที่ 6:00 กับพักรับประทานอาหารกลางวันเวลา 11:30 AM, TIMESTAMP WITHOUT TIME ZONEที่สามารถบันทึกเป็น อีกครั้งข้อมูลนี้มีประโยชน์ในทางที่คลุมเครือ แต่ไม่ได้ระบุช่วงเวลาที่เฉพาะเจาะจงจนกว่าเราจะใช้เขตเวลา รุ่งอรุณวันใหม่เร็วขึ้นในภาคตะวันออก ดังนั้นโรงงานของนิวเดลีจะเป็นแห่งแรกที่เปิดในเวลา 6.00 น. ชั่วโมงต่อมาโรงงานDüsseldorfเริ่มทำงานเวลา 6.00 น. แต่โรงงานดีทรอยต์จะไม่เปิดจนกว่าจะถึงอีกหกชั่วโมงต่อมาเมื่อเวลา 6.00 น. เกิดขึ้น

เปรียบเทียบความคิดนี้ (เมื่อการเปลี่ยนแปลงของโรงงานเริ่มต้น) กับข้อเท็จจริงทางประวัติศาสตร์ของเมื่อใดที่คนงานในโรงงานแต่ละคนทำงานนาฬิกาเข้า - ออกเพื่อเริ่มการเปลี่ยนแปลงในวันใดวันหนึ่ง นาฬิกาเป็นช่วงเวลาที่แท้จริงซึ่งเป็นจุดที่เกิดขึ้นจริงบนเส้นเวลา ดังนั้นเราจะบันทึกลงในคอลัมน์ประเภทTIMESTAMP WITH TIME ZONEมากกว่าWITHOUTประเภท

TIMESTAMP WITHOUT TIME ZONEดังนั้นใช่มีถูกต้องตามกฎหมายกรณีการใช้งานสำหรับ แต่จากประสบการณ์ของฉันกับแอพทางธุรกิจพวกมันค่อนข้างหายาก ในธุรกิจเรามักจะสนใจเกี่ยวกับช่วงเวลาที่แท้จริง: ใบแจ้งหนี้มาถึงจริงเมื่อใดเมื่อสัญญาดังกล่าวมีผลบังคับใช้จริง ณ เวลาใดที่ธุรกรรมของธนาคารนั้นดำเนินการ ดังนั้นในสถานการณ์ทั่วไปเราต้องการTIMESTAMP WITH TIME ZONEพิมพ์

สำหรับการสนทนาเพิ่มเติมให้ดูคำตอบของคำถามที่คล้ายกันฉันควรจัดเก็บเวลาประทับ UTC หรือเวลาท้องถิ่นสำหรับการเปลี่ยนแปลง

Postgres

โปรดทราบว่า Postgres จะไม่บันทึกข้อมูลโซนเวลาที่ระบุไว้โดยเฉพาะเมื่อทำการแทรกการประทับเวลา

• TIMESTAMP WITH TIME ZONE
  • เขตเวลาใด ๆ ที่ระบุหรือออฟเซ็ตรวมอยู่กับข้อมูลอินพุตจะใช้เพื่อปรับค่าเป็น UTC และเก็บไว้ ข้อมูลโซน / ออฟเซ็ตที่ผ่านไปจะถูกยกเลิก คิดว่าเป็นTIMESTAMP WITH TIME ZONETIMESTAMP WITH RESPECT FOR TIME ZONE
  • เวลา 12.00 น. ของวันที่ 7 มีนาคมปีนี้ในอินเดียจะมีการปรับเวลาเป็น UTC โดยการลบชั่วโมงห้าชั่วโมงครึ่ง: 6.30 น.
• TIMESTAMP WITHOUT TIME ZONE
  • เขตเวลาใด ๆ ที่ระบุหรือออฟเซ็ตที่รวมอยู่ในข้อมูลอินพุตจะถูกละเว้นทั้งหมด
  • ข้อมูลนำเข้าเวลา 12.00 น. ของวันที่ 7 มีนาคมปีนี้ในประเทศอินเดียบันทึกเป็นเวลา 12:00 น. ของวันที่ 7 มีนาคมของปีนี้โดยไม่มีการปรับเปลี่ยน

มาตรฐาน SQL แทบจะไม่ได้สัมผัสกับปัญหาของชนิดข้อมูลและวันที่และเวลา ดังนั้นฐานข้อมูลจึงแตกต่างกันอย่างมากในการจัดการวันเวลา

ฉันต้องการเพิ่มมุมมองอื่นให้กับสิ่งนี้ซึ่งขัดแย้งกับสิ่งที่เขียนไว้ในคำตอบอื่น ๆ ในความคิดของฉันtimestamp with time zoneมีกรณีการใช้งานที่ถูกต้องน้อยมากและtimestamp without time zoneโดยทั่วไปแล้วควรเป็นที่ต้องการ

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

หากคุณติดตามรูปแบบนี้แสดงว่าเป็นรูปแบบtimestamp with time zoneการต่อต้าน ประเภททั้งหมดนี้ทำให้ PostgreSQL ดำเนินการแปลงเขตเวลาเมื่ออ่านและเขียนบันทึกเวลาตามTimeZoneตัวแปรเซสชันPostgreSQL ของคุณ แทนที่จะจัดการกับเขตเวลาที่ขอบสุดของแอปพลิเคชันของคุณคุณได้แนะนำพวกเขาเข้ามาในหัวใจเพื่อการสื่อสารกับฐานข้อมูลของคุณ คุณต้องดูแลให้มีTimeZoneการกำหนดค่าPostgreSQL อย่างถูกต้องตลอดเวลาเพิ่มจุดของความล้มเหลวและความสับสนที่ไม่จำเป็น

และเพื่ออะไร หากคุณติดตามรูปแบบ UTC ทุกที่แอปพลิเคชันของคุณจะมีการประทับเวลา UTC เท่านั้น เหตุใดจึงขอให้ฐานข้อมูลของคุณทำการแปลงเขตเวลากับพวกเขา คุณสามารถเก็บไว้ในtimestamp without time zoneคอลัมน์และจัดการกับมันเหมือนเป็น UTC เสมอ ไม่มีการแปลงไม่มีเขตเวลาไม่มีภาวะแทรกซ้อน

การdateประทับเวลายังไม่รวมข้อมูลเขตเวลา แต่มีผู้ใช้จำนวนมากใช้

แน่นอนว่าของตัวเองไม่ได้คำตอบ

สามารถใช้งานได้timestampและdateสำหรับการประทับเวลาและวันที่ใด ๆ ที่มักจะอยู่ในเขตเวลาเดียวกันหรือจะถูกเก็บไว้เมื่อเทียบกับเขตเวลาที่รู้จัก

หากเขตเวลานั้นเหมือนกันหรือโดยปริยายก็เป็นเรื่องของ antipattern ที่จะเก็บมันมากกว่าที่จะไม่เก็บมันไว้ (ข้อมูลซ้ำซ้อน)

Timestamps ยังสามารถใช้สำหรับจัดเก็บข้อมูลทางเทคนิคเช่นใช้ในบันทึกการใช้งานหรือการวัดประสิทธิภาพ ในกรณีนี้เขตเวลาอาจไม่สำคัญ

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

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

เมื่อเปลี่ยนกลับจากการปรับเวลาตามฤดูกาลเป็นเวลามาตรฐานจะมีการทำซ้ำชั่วโมงในเวลาท้องถิ่น (สมมติว่าความแตกต่างคือหนึ่งชั่วโมง) ที่ฉันอาศัยอยู่สิ่งนี้มักจะเกิดขึ้นประมาณตี 2 ดังนั้นเวลาท้องถิ่นจะเปิดเวลา 01:58, 01:59, 01:00 น. และจะถึงเวลา 02:00 น. ในตอนท้ายของชั่วโมงซ้ำ

หากคุณพยายามจัดลำดับเหตุการณ์ตามเวลาโดยใช้เวลาท้องถิ่นนั่นหมายถึงเหตุการณ์จากสองชั่วโมงที่รวมเข้าด้วยกันและไม่ปรากฏตามลำดับที่เกิดขึ้นจริง

โดยการเปรียบเทียบ UTC ไม่มีปัญหานี้และสั่งซื้อได้อย่างหมดจด ดังนั้นแม้เมื่อทำงานกับเขตเวลาเดียวคุณต้องการให้ DB เก็บและประมวลผลเวลาใน UTC และแปลงเป็น / จากเวลาท้องถิ่นสำหรับอินพุต / จอแสดงผล นี่คือพฤติกรรมของ TIMESTAMP WITH TIME ZONE