Rust के लिए तारीख़-समय लाइब्रेरी Jiff
(github.com/BurntSushi)- Jiff Rust के लिए एक तारीख़-समय लाइब्रेरी है, जिसका लक्ष्य ऐसे high-level तारीख़-समय primitive types देना है जिनका गलत उपयोग करना कठिन हो, साथ ही उचित performance प्रदान करना
- इसकी मुख्य विशेषताओं में Time Zone Database के साथ स्वचालित एकीकरण, DST-aware arithmetic और rounding, time zone सहित तारीख़-समय का lossless formatting·parsing, और वैकल्पिक Serde support शामिल हैं
- API डिज़ाइन पर JavaScript में तारीख़-समय हैंडलिंग सुधारने वाले TC39 प्रस्ताव Temporal का बड़ा प्रभाव है
- Jiff 1.0 का मूल लक्ष्य 2025 की गर्मियों में रिलीज़ करना था, लेकिन अप्रैल 2026 तक शेड्यूल खिसक चुका है और फिलहाल 1.0 रिलीज़ की कोई समयरेखा नहीं है
- performance एक महत्वपूर्ण लक्ष्य है, लेकिन API की समझने-योग्यता और शुद्धता को प्राथमिकता दी जाती है, और Unix पर यह जानबूझकर zero dependencies बनाए रखने वाली सतर्क dependency policy अपनाता है
Jiff द्वारा प्रदान किया गया तारीख़-समय मॉडल
- Jiff Rust में तारीख़-समय संभालने के लिए एक लाइब्रेरी है, जिसका फोकस ऐसे high-level primitive types देने पर है जिनका गलत उपयोग करना कठिन हो
- मुख्य समर्थित सुविधाएँ
- Time Zone Database के साथ स्वचालित और सहज एकीकरण
- DST-aware arithmetic और rounding
- time zone सहित तारीख़-समय का lossless formatting·parsing
- वैकल्पिक
serdesupport
- API डिज़ाइन पर JavaScript में तारीख़-समय हैंडलिंग सुधारने के लिए बने TC39 प्रस्ताव Temporal का बड़ा प्रभाव है
- लाइसेंस MIT या UNLICENSE dual license है
दस्तावेज़ और उपयोग उदाहरण
- दस्तावेज़ और संबंधित सामग्री
- docs.rs पर API दस्तावेज़
chrono,time,hifitime,icuके साथ तुलना दस्तावेज़- Jiff API डिज़ाइन का rationale दस्तावेज़
- platform support दस्तावेज़
- changelog
- बुनियादी उदाहरण RFC 3339 टाइमस्टैम्प स्ट्रिंग को parse करने के बाद उसे time zone सहित तारीख़-समय में बदलता है, फिर एक अवधि जोड़कर उसे lossless स्ट्रिंग के रूप में आउटपुट करता है
"2024-07-11T01:14:00Z"कोTimestampके रूप में parse करनाAmerica/New_Yorktime zone में बदलना1.month().hours(2)जोड़ना- परिणाम स्ट्रिंग
"2024-08-10T23:14:00-04:00[America/New_York]" - RFC 3339 फ़ॉर्मैट का UTC समय
"2024-08-11T03:14:00Z"
इंस्टॉलेशन और बुनियादी रन फ़्लो
- Jiff crates.io पर उपलब्ध है और इसे Rust प्रोजेक्ट की
Cargo.tomldependencies मेंjiffजोड़कर इस्तेमाल किया जा सकता है - आसान add कमांड है
cargo add jiff - README का पूरा उदाहरण फ़्लो
cargo new jiff-exampleसे नया प्रोजेक्ट बनानाcargo add jiffसे dependency जोड़नाsrc/main.rsमेंZoned::now().round(Unit::Second)?से वर्तमान समय को सेकंड स्तर पर round करनाcargo runसे चलाना
- उदाहरण आउटपुट time zone सहित
2024-07-10T19:54:20-04:00[America/New_York]जैसा रूप दिखाता है - पहली बार चलाने पर अधिक compile output दिखेगा, लेकिन बाद की runs में dependencies को दोबारा compile करने की ज़रूरत नहीं होगी
feature flags और 1.0 योजना
- Jiff कई crate features देता है, जिनसे Rust standard library support,
serdesupport, और Time Zone Database को binary में embed करना है या नहीं, यह नियंत्रित किया जा सकता है - समर्थित सभी feature flags की सूची दस्तावेज़ के “crate features” सेक्शन में है
- Jiff 1.0 की मूल रिलीज़ योजना 2025 की गर्मियों की थी, लेकिन अप्रैल 2026 तक शेड्यूल पहले ही खिसक चुका है और अभी कोई रिलीज़ समयरेखा नहीं है
- 1.0 रिलीज़ के बाद API को अनिश्चितकाल तक बनाए रखने की योजना है, ताकि उपयोगकर्ता Jiff को public API के स्थिर आधार के रूप में इस्तेमाल कर सकें
- Jiff 1.0 रिलीज़ के बाद भी Jiff 0.2 को 1 साल तक महत्वपूर्ण bug fix updates मिलते रहेंगे
- कोई सक्रिय feature development नहीं होगा
- पहले से Jiff 0.2 इस्तेमाल करने वाले उपयोगकर्ताओं को migration grace period देने की योजना है
performance और उन्नत formatting path
- सबसे महत्वपूर्ण डिज़ाइन लक्ष्य एक ऐसी high-level तारीख़-समय लाइब्रेरी बनना है जिसका गलत उपयोग करना कठिन हो
- performance दूसरा लक्ष्य है; उचित performance देना उद्देश्य है, लेकिन कुछ क्षेत्रों में सुधार की गुंजाइश हो सकती है
- benchmarks
benchdirectory में हैं - कुछ क्षेत्रों का optimization हो चुका है, लेकिन अभी भी कई हिस्से optimized नहीं हैं
- performance सुधार एक लक्ष्य है, लेकिन सामान्यतः API की समझने-योग्यता और शुद्धता को performance से ऊपर रखा जाता है
- Jiff के submodules, खासकर
jiff::fmt, अधिक नियंत्रण चाहने वाले जटिल APIs के लिए escape hatch की तरह काम करते हैंZonedकाstd::fmt::Displayimplementation reusable buffer में लिखना कठिन बना सकता हैjiff::fmt::temporal::DateTimePrinter::print_zonedZonedको मौजूदाStringयाVec<u8>में लिखने देता है
platform के अनुसार time zone हैंडलिंग
- तारीख़-समय लाइब्रेरी में platform support की समस्या मुख्यतः time zone support से जुड़ी होती है
- Jiff जिन platform interactions को संभालता है
Antarctica/Trollजैसे IANA time zone identifiers के transition data को कैसे ढूँढना है- वर्तमान सिस्टम का default time zone कैसे पता करना है
- time zone transition data IANA Time Zone Database पर निर्भर करता है
- Unix पर सामान्यतः
/usr/share/zoneinfoका उपयोग किया जाता है, औरTZDIRenvironment variable setting का भी पालन किया जाता है - Windows पर compiled library में Time Zone Database की एक कॉपी स्वतः embed की जाती है
- system time zone detection का तरीका
- Unix पर
/etc/localtimeपढ़ा जाता है - Windows पर
GetDynamicTimeZoneInformationसे Windows-विशिष्ट time zone identifier पढ़ा जाता है, और Unicode के CLDR XML data के माध्यम से उसे IANA time zone identifier में map किया जाता है
- Unix पर
- अन्य platforms का support समय के साथ बढ़ने की उम्मीद है, लेकिन जिन दुर्लभ platforms का परीक्षण करना कठिन है, उनके लिए संभवतः contributors के pull requests पर निर्भर रहना पड़ेगा
dependencies और MSRV नीति
- Unix पर Jiff का zero dependencies होना जानबूझकर किया गया डिज़ाइन है
- ecosystem crate के रूप में Jiff में नई dependency जोड़ने के मानदंड सतर्क हैं
- जब platform के साथ interaction के लिए वास्तव में ज़रूरी हो
- जब interoperability के लिए ज़रूरी हो, जैसे
serde
- interoperability के उद्देश्य वाली dependencies को भी सतर्कता से देखा जाता है, और सामान्यतः उन्हीं पर निर्भर रहने की कोशिश होती है जिनकी breaking change releases Jiff की तुलना में कम होती हैं
- अगर Jiff को कई crates में बाँटा जाता है तो नई dependencies आ सकती हैं, लेकिन अभी ऐसा कोई प्लान नहीं है
- crates की संख्या कम रखने की दिशा है, क्योंकि कई semver API boundaries को संभालने का maintenance overhead बड़ा होने का अनुभव रहा है
- Jiff का minimum supported Rust compiler version MSRV 1.70.0 है
- Jiff स्वयं और repository में मौजूद Jiff dependencies ऐसे Rust versions का उपयोग नहीं करते जिन्हें पिछले 1 साल के भीतर रिलीज़ हुए Rust compiler की आवश्यकता हो
jiff-icuजैसे repository के अंदर Jiff पर निर्भर crates अधिक नया MSRV इस्तेमाल कर सकते हैं, लेकिन वे उस integration target crate से नया MSRV नहीं माँगेंगेwindows-sys,portable-atomicजैसी बाहरी dependencies का MSRV Jiff के नियंत्रण में नहीं है- Rust ecosystem की परंपरा के अनुसार Jiff MSRV बढ़ोतरी को semver-incompatible change नहीं मानता, लेकिन MSRV वृद्धि को minor version update तक सीमित रखता है
1 टिप्पणियां
Hacker News की राय
कुल मिलाकर अच्छा लगता है, लेकिन ToSpan syntax पर थोड़ा अटका
let span = 5.days().hours(8).minutes(1);यह तरीका अजीब लगा कि केवल पहला नंबर आगे आता है और बाकी function arguments में जाते हैं
अगर पसंद न हो तो
let span = Span::new().days(5).hours(8).minutes(1);की तरह लिख सकते हैं, और बस कुछ अक्षर बढ़ते हैं, इसलिए बुरा नहीं हैuse jiff::{Timestamp, ToSpan};के बाद"2024-07-11T01:14:00Z".parse()?का Timestamp के रूप में parse होना अटकामुझे याद है कि Rust classes की जगह interfaces जैसी चीज़ें इस्तेमाल करता है, लेकिन library import करने पर string में अचानक
parse()method कैसे आ जाता है, और उस generic नाम वाले method सेTimestampobject क्यों बनता है, यह समझना चाहता हूँक्या left-side type
str.parse()का मतलब तय करता है, और अगर कोई date library और Lisp expression library दोनों strings परparse()लगा दें तो क्या होगा, यह भी जानना चाहता हूँयहाँ तक कि
Timestamp.parse(str)जैसी syntax क्यों नहीं इस्तेमाल होती, इस पर भी कई सवाल उठते हैंlet span = 5.days() + 8.hours() + 1.minutes();ज्यादा पसंद हैमूल syntax Ruby जैसी लगती है
code पढ़ते समय पहले यह दिखे कि span handle कर रहे हैं, तो बेहतर होगा
let span = Span::days(5).hours(8).minutes(1);ज्यादा अच्छा लगता हैdate/time libraries की complexity को कम आंकते हुए बहुत बार देखा है
“internal representation UTC/Unix time में रखो”, “duration को nanoseconds में दिखा दो”, “time zones की जगह सिर्फ offsets इस्तेमाल करो” जैसी बातें बार-बार आती हैं
अगर ऐसा सोचते हैं, तो Jiff का design document पढ़ना अच्छा रहेगा: https://github.com/BurntSushi/jiff/blob/master/DESIGN.md
BurntSushi के काम की तरह यह शानदार और detailed है
Rust की de facto standard date/time library chrono से तुलना भी पढ़ने लायक है: https://docs.rs/jiff/latest/jiff/_documentation/comparison/i...
serialization/deserialization के बाद भी सही रहने वाली DST arithmetic, rounding योग्य durations, time zone-aware calendar arithmetic, historical time zone conflicts की detection जैसी चीज़ें library को accurate, useful और इस्तेमाल में अच्छा बनाती हैं
chrono comprehensive और “accurate” library है, लेकिन rigid थी और इस्तेमाल में आसान नहीं थी
Debian के
rgdefault रूप से देने से पहले से ही मैं ripgrep इस्तेमाल कर रहा था, और उस दौर में JodaTime भी इस्तेमाल किया था जब कुछ लोग Eclipse को IntelliJ IDEA से बेहतर मानते थेलेकिन उस document में कहीं भी “duration को nanoseconds में दिखा दो” का खंडन नहीं है
users को time zone और DST के हिसाब से सही समय दिखना चाहिए, लेकिन programs को आम तौर पर इसकी जरूरत नहीं होती
अगर काम कई time zones को सीधे handle करने का नहीं है, तो duration को milliseconds/nanoseconds में represent करना आम तौर पर बहुत safe है
इंसानों ने time zones और DST बनाए हैं, इससे CPU की internal clock का प्रति सेकंड अरबों बार टिक करने वाला physical phenomenon नहीं बदल जाता
कुछ दिन पहले पृथ्वी के आधे हिस्से में न फटे operating system kernels को ही देखें, तो code में timeouts कई जगह milliseconds में represent किए गए हैं
“30-second cooldown” implement करते समय current time zone में 30 seconds जोड़ना, उसे time zone·DST·12/24-hour notation सहित string के रूप में store करना, और leap second है या नहीं, यह भी check करना पड़ेगा—ऐसी गलतफहमी हो सकती है
बस milliseconds में represent किया हुआ 30-second timeout/cooldown इस्तेमाल करें, और user के हिसाब से वह 29 seconds बाद हो जाए तो भी leap second की चिंता करने की जरूरत नहीं है
बढ़िया लाइब्रेरी लगती है
जिज्ञासा है कि BurntSushi नई लाइब्रेरी क्यों बना रहे हैं
Rust में time handling मैंने ज़्यादा नहीं की है, इसलिए जानना चाहता हूँ कि क्या मौजूदा libraries में performance issues हैं, मौजूदा API इस्तेमाल करने में असुविधाजनक है, या बस मज़े के लिए कर रहे हैं—या कोई और वजह है
Java standard library का implementation अच्छा नहीं था, और उस समस्या को हल करने के लिए JodaTime आया था
बाद में Java 8 में JodaTime से काफ़ी प्रभावित नया DateTime API शामिल हुआ, और क्योंकि वह standard library में था, library authors उसे ज़्यादा व्यापक रूप से अपना सके
https://www.joda.org/joda-time/
https://www.baeldung.com/java-8-date-time-intro
https://github.com/BurntSushi/jiff/blob/master/DESIGN.md
https://github.com/BurntSushi/jiff/blob/master/COMPARE.md
सार यह है कि वजह मुख्य रूप से API और IANA timezone support है
Rust की calendar libraries की स्थिति बहुत आदर्श नहीं है
Pandas में
.tz_convert()और.tz_localize()हैं, और timezone conversion के लिए व्यावहारिक रूप से बस वही काफ़ी हैमेरा benchmark काम है “किसी दिए गए date के लिए CET/CEST दिन का पहला hour UTC में निकालना”, और Pandas में यह बेहद आसान है
Chrono में
NaiveDateबनाना पड़ता है, फिर उसेDateTimeमें बदलना होता है, और फिर दोबाराDateTimeमें बदलना पड़ता है; ऐसी conversions में मुझे कोई consistent pattern नहीं मिलाकभी यह member function होता है, तो कभी timezone object का static method
उम्मीद है कि किसी दिन कोई इसे ठीक करेगा। Jiff सही दिशा में एक कदम जैसा लगता है, लेकिन syntax कभी-कभी अजीब है, इसलिए मैं और predictable रूप चाहता हूँ
date(y, m, d).intz("Europe/Rome")?से किया जा सकता हैअगर वहाँ से UTC पाना हो, तो
with_time_zone(TimeZone::UTC)जोड़ देंJiff कैसे और बेहतर हो सकता है, और syntax अजीब लगने वाली बात को थोड़ा और समझाएँ तो अच्छा होगा
“जान, उठो, नया BurntSushi आ गया है”[0]
गंभीरता से कहूँ तो, यहाँ Rust users में से कोई जानता है कि यह crate
tracingजैसी चीज़ क्यों नहीं इस्तेमाल करता?शायद वह बहुत heavy हो। crate के हिसाब से size लगभग आधा है
logभी बिल्कुल ठीक है, और मुझे नहीं पता timezone operations की calls तक trace करना आम use case है या नहीं, लेकिन जानना चाहता हूँ कि क्या कोई खास वजह थी[0] https://knowyourmeme.com/memes/wake-up-babe
loglowest common denominator के काफ़ी करीब हैयह
tracingके साथ भी अच्छी तरह integrate होता है, इसलिए Jiff में इसे इस्तेमाल करने की वजह शायद यही हैcrates.io के शुरुआती दिनों से भी इसका इस्तेमाल होता आ रहा है
Jiff की ज़रूरत सिर्फ़ किसी खास log level पर messages emit करने की है, उससे ज़्यादा कुछ नहीं
बेशक
tracingभी ठीक से काम करता, ऐसा लगता हैBurntSushi Rust के पूरे regex ecosystem को बनाने वाले व्यक्ति भी हैं
Rust हो या कोई और ecosystem, मौजूदा time libraries में जो बात सबसे ज़्यादा खटकती है वह leap second support की कमी है
आम तौर पर वे internally TAI के बजाय UNIX timestamp इस्तेमाल करती हैं, और अफ़सोस कि यह library भी अलग नहीं है
लगता है tzif files के ज़रिए कुछ हद तक support करने का तरीका है, लेकिन यह first-class support नहीं है
संबंधित Jiff issue में details हैं: https://github.com/BurntSushi/jiff/issues/7
UNIX timestamp SI second की definition इस्तेमाल नहीं करता, बल्कि मौजूदा दिन का 1/86000 इस्तेमाल करता है, इसलिए सभी UNIX seconds की length समान नहीं होती और सही duration calculations टूट जाती हैं
मैं समझता हूँ कि यह पुराने time tracking तरीकों के साथ compatibility विरासत में लेने और calendar formatting को तेज़ रखने का trade-off था, लेकिन मुझे नहीं लगता कि यह सही trade-off था
UNIX timestamp presentation concerns को data के साथ मिला देता है
मेरे हिसाब से leap seconds को 29 February या timezones की तरह ही handle किया जाना चाहिए
hifitimeजैसी specialized scientific library उपयुक्त क्यों नहीं है?leap seconds की बात आते ही चर्चा अक्सर abstract बातों में चली जाती लगती है
बहुत कम ही यह real-world use cases से जुड़ती है
scientific use cases समझ में आते हैं, और मुझे लगता है specialized libraries उन उद्देश्यों को अच्छी तरह handle करती हैं
उसके अलावा और क्या चाहिए, यह मुझे ठीक से समझ नहीं आता
Jiffको hard G के साथ pronounce किया जाता है, यानी “Giff”goवाला G, याginवाला G?“Jiff को
gemजैसे soft g वालेgifकी तरह pronounce करते हैं।”बिल्कुल नहीं!
मैं chrono पर ही रहूँगा †
† बेशक इसे
chaseकेchकी तरह pronounce करके “trono” कहते हैंतो इसका उच्चारण jiff है, या gif?
“Jiff का उच्चारण
gemकी तरह soft g वालेgifजैसा है।”अच्छा, अब समझ आया यह किस तरह का मज़ाक है…
GIF, उसके creator के मुताबिक, हमेशा “jif” ही बोला गया है, इसलिए confusion से बचने के लिए अच्छा होगा कि इस नए tool का creator Jiff को “gif” बोल दे