Unix დროის შტამპები, თავის ტკივილის გარეშე
ჰკითხეთ სამ დეველოპერს, რომელი საათია, და, სავარაუდოდ, სამ სხვადასხვა პასუხს მიიღებთ, იმის მიხედვით, სად სხედან. ჰკითხეთ Unix დროის შტამპს, და ერთსავე რიცხვს მიიღებთ — იმავეს ყველასთვის პლანეტაზე. სწორედ ეს ერთი მთელი რიცხვია მიზეზი, რის გამოც epoch დრო ჩუმად უდევს საფუძვლად თითქმის ყოველ ლოგის ფაილს, ბაზის ჩანაწერსა და API პასუხს, რომელსაც ოდესმე შეხვდებით. ეს გვერდი განმარტავს, რას ნიშნავს ეს რიცხვი, როგორ იკითხება ის ორივე მიმართულებით, და სად ბორტავს ხოლმე ხალხს.
რას წარმოადგენს Unix დრო სინამდვილეში
Unix დროის შტამპი არის წამების რაოდენობა, რომელიც 1970 წლის 1 იანვრის 00:00:00 UTC-დან გავიდა, გადახტომილი წამების ჩაუთვლელად. ეს მომენტი epoch-ად, ანუ ეპოქად იწოდება, და ის ადრეულმა Unix ინჟინრებმა შეარჩიეს უბრალოდ იმიტომ, რომ ეს მოსახერხებელი, მრგვალი თარიღი იყო ათვლის დასაწყებად. epoch-ზე მნიშვნელობა ზუსტად 0-ია. ყოველი მომდევნო წამი ერთს უმატებს, ასე რომ, რიცხვი მხოლოდ იზრდება. 1970 წლამდე თარიღებიც სავსებით ვალიდურია, უარყოფითი მთელი რიცხვებით გამოსახული.
ამ კონცეფციას ასევე POSIX დროსაც უწოდებენ, ან, ხშირად, უბრალოდ epoch დროს. სახელწოდება რაც არ უნდა იყოს, მექანიკა იგივეა: ერთი, უწყვეტად მზარდი წამების მთვლელი. რადგან ეს უბრალო მთელი რიცხვია და არა დაფორმატებული სტრიქონი, კომპიუტერს მისი შენახვა რამდენიმე ბაიტში შეუძლია, და ორი ასეთი მნიშვნელობის შედარებაც ერთი გამოკლებით.
წამები, მილიწამები და ნათესავები
კლასიკური Unix დრო მთელ წამებს ითვლის, რაც დღეს ცნობილ, ათციფრიან რიცხვს იძლევა. მაგრამ ბევრ გარემოს უფრო ძვირფასი გარჩევადობა სჭირდება. JavaScript, მაგალითად, მილიწამებში მუშაობს, თერთმეტციფრიან — ანუ, ზუსტად რომ ვთქვათ, ცამეტციფრიან — მნიშვნელობას აწარმოებს, ხოლო ზოგიერთი სისტემა კიდევ უფრო შორს მიდის, მიკროწამებამდე ან ნანოწამებამდე. საიმედო წესი: ათციფრიანი რიცხვი წამებია, ცამეტციფრიანი — მილიწამები. თუ თქვენი გარდაქმნილი თარიღი 1970 წლის ახლოს ხვდება, სანამ ამჟამინდელ დღეს ელოდით, თითქმის დარწმუნებული ბრძანდებით, რომ მილიწამები წამების ველში ჩააგდეთ, ან პირიქით. ჩვენი გადამყვანი მასშტაბს ავტომატურად ცნობს, ასე რომ, გამოცნობა იშვიათად გჭირდებათ.
რატომ ეყრდნობიან მას დეველოპერები
დიდი უპირატესობა ისაა, რომ დროის შტამპი დროის სარტყელისგან დამოუკიდებელია. მთელი რიცხვი 1735689600 იმავე მომენტს აღნიშნავს ტოკიოში, ბერლინსა და სან-პაულუში. ამ რიცხვის შენახვა დაფორმატებული ლოკალური სტრიქონის ნაცვლად ნიშნავს, რომ არასდროს მოგიწევთ გაფიქრება, რომელ საათს ეკუთვნოდა მნიშვნელობა. დახარისხებაც ტრივიალურია, რადგან ქრონოლოგიური თანმიმდევრობა უბრალოდ რიცხვითი თანმიმდევრობაა, ასე რომ, ბაზის ინდექსი დროის შტამპის სვეტზე მოვლენებს პარსინგის გარეშე სწორად ალაგებს. არითმეტიკაც ისევე სუფთაა: ორ მოვლენას შორის უფსკრული ერთი გამოკლებაა, ხოლო დღის დამატება — 86400-ის დამატება. სწორედ ეს თვისებებია მიზეზი, რის გამოც ლოგები, ტოკენები, ქეშები და შეტყობინებათა რიგები epoch დროს მიმართავენ.
გარდაქმნა ორივე მიმართულებით
დროის შტამპიდან ადამიანურ თარიღზე გადასვლა ნიშნავს წამების რაოდენობის კალენდარზე პროექციას, შემდეგ მისი დაფორმატებას იმ დროის სარტყელში, რომელიც გაინტერესებთ. საპირისპირო მიმართულებით, იღებთ წელს, თვეს, დღეს და დროს, წყვეტთ, რომელ დროის სარტყელშია ის გამოსახული, და ისევ epoch-იდან წამებამდე აქცევთ. ჩვენი ხელსაწყო ორივე მიმართულებას მყისვე და მთლიანად თქვენს ბრაუზერში ასრულებს, ასე რომ, არაფერი, რასაც ჩასვამთ, თქვენს მოწყობილობას არ ტოვებს. ჩასვით რიცხვი მისი გასაშიფრად, ან აირჩიეთ თარიღი მის დასაკოდირებლად, და წაიკითხეთ შედეგი ერთდროულად UTC-შიც და თქვენს ლოკალურ დროშიც.
UTC თუ ლოკალური დრო — კლასიკური ხაფანგი
თავად დროის შტამპს დროის სარტყელი არ გააჩნია; ის ყოველთვის UTC-ზეა მიბმული. დაბნეულობა მხოლოდ ჩვენების დროს ჩნდება. თუ 1700000000-ს გარდაქმნით და თქვენი ეკრანი საღამოს საათს გიჩვენებთ, სანამ სხვა ქვეყანაში მყოფი კოლეგა შუადღის საათს ხედავს, არაფერია გატეხილი — ორივენი ერთსა და იმავე მომენტს უყურებთ, უბრალოდ სხვადასხვა ლოკალურ საათზე ასახულს. ხარვეზები მაშინ ჩნდება, როცა კოდი ლოკალურ თარიღს UTC-სავით კითხულობს, ან საათის მნიშვნელობას მისი ოფსეტის ჩაწერის გარეშე ინახავს. უსაფრთხო ჩვევაა UTC-ის შენახვა და გადაცემა, და ლოკალური ოფსეტის გამოყენება მხოლოდ ბოლო მომენტში, როცა მნიშვნელობას ადამიანს უჩვენებთ. ეჭვის შემთხვევაში, შეადარეთ გადამყვანის UTC ხაზს და არა ლოკალურს.
2038 წლის პრობლემა
ბევრი ძველი სისტემა Unix დროს ინახავდა 32-ბიტიან, ნიშნის მქონე მთელ რიცხვში. ეს ველი ადგილს ამოწურავს 2038 წლის 19 იანვრის 03:14:07 UTC-დან ერთი წამის შემდეგ, როცა მთვლელი გადმოდის და უარყოფით რიცხვად „ეხვევა", თარიღებს პოტენციურად 1901 წლისკენ აბრუნებს. ეს იმავე ოჯახის პრობლემაა, რაც Y2K. სასიხარულო ისაა, რომ თანამედროვე საოპერაციო სისტემები და ენები დიდწილად 64-ბიტიან დროის შტამპებზე გადავიდნენ, რომლებიც არ გადავა დაახლოებით 292 მილიარდი წლის განმავლობაში, ასე რომ, ახალი კოდისთვის ეს, ძირითადად, ისტორიული ცნობისმოყვარეობაა და არა გადაუდებელი საკითხი.
მეტი ბრაუზერზე დაფუძნებული დამხმარეებისთვის იხილეთ ჩვენი დეველოპერული ხელსაწყოები, ხოლო თუ თავად რიცხვებთან გჭირდებათ მუშაობა, კალკულატორები ერთი დაწკაპუნებით ხელმისაწვდომია.
ხშირად დასმული კითხვები
რა არის Unix დროის შტამპი?
ეს არის წამების რაოდენობა 1970 წლის 1 იანვრის 00:00:00 UTC-დან, გადახტომილი წამების ჩაუთვლელად. ეს საწყისი მომენტი epoch-ად იწოდება, და მთვლელი დროთა განმავლობაში მხოლოდ იზრდება.
რატომ გარდაიქმნება ჩემი რიცხვი 1970 წლის ახლო თარიღად?
სავარაუდოდ, წამები და მილიწამები აგერიათ. ათციფრიანი რიცხვი წამებია, ცამეტციფრიანი — მილიწამები. მილიწამების წამების ველში ჩადება ხილულ დროს დაახლოებით ათასჯერ ამცირებს, რაც თითქმის epoch-თან გახდის.
აქვს Unix დროის შტამპს დროის სარტყელი?
არა. მნიშვნელობა ყოველთვის UTC-ზეა მიბმული. დროის სარტყელი მხოლოდ მაშინ ჩნდება, როცა დროის შტამპს ადამიანურად წაკითხვად თარიღად აჩვენებთ, სწორედ ამიტომ შეუძლია ერთსა და იმავე რიცხვს სხვადასხვა ადამიანისთვის სხვადასხვა საათი აჩვენოს.
როგორ გარდავქმნა თარიღი უკან, დროის შტამპად?
მიუთითეთ წელი, თვე, დღე და დრო, გადაწყვიტეთ, რომელ დროის სარტყელშია ეს თარიღი გამოსახული, და ხელსაწყო მას epoch-იდან წამებამდე აქცევს. ორივე მიმართულების შესრულება ამ გვერდზე მყისვე, თქვენს ბრაუზერშივე შეგიძლიათ.
რა არის 2038 წლის პრობლემა?
სისტემები, რომლებიც Unix დროს 32-ბიტიან, ნიშნის მქონე მთელ რიცხვში ინახავენ, 2038 წლის 19 იანვრის 03:14:07 UTC-დან ერთი წამის შემდეგ გადავლენ. თანამედროვე 64-ბიტიანი დროის შტამპები ამას მილიარდობით წლის განმავლობაში ვერიდება, ასე რომ, დღევანდელი პროგრამების უმეტესობას ეს არ ეხება.
იგზავნება ჩემი მონაცემი სერვერზე?
არა. გარდაქმნა მთლიანად თქვენს ბრაუზერში ხდება, ასე რომ, ნებისმიერი დროის შტამპი ან თარიღი, რომელსაც ჩასვამთ, თქვენსავე მოწყობილობაზე რჩება.