प्रोग्रामर आईएसओ मानकों की अनदेखी क्यों करेंगे? [बन्द है]


18

जिन चीज़ों को मैं अक्सर चलाता हूं उनमें से एक है कार्यक्रमों के कारण होने वाली समस्याएं जो आईएसओ मानकों के अनुरूप नहीं हैं।

एक उदाहरण आईएसओ देश की तालिकाओं का उपयोग नहीं करना है, लेकिन अपने स्वयं के शॉर्टहैंड बनाना है, जो संयुक्त राज्य अमेरिका (यूएस), या नीदरलैंड (एनएल) के लिए ठीक है, लेकिन यूनाइटेड किंगडम (जीबी, यूके नहीं) या स्पेन के लिए शानदार रूप से गलत है (ईएस, एसपी नहीं) और बहुत सारे अन्य देश।

एक अन्य उदाहरण के रूप में, आंतरिक तिथि अंकन। क्यों कोई 01/02/2014 के रूप में एक तारीख स्टोर करेगा? यह पूरी तरह से स्पष्ट नहीं है कि यह 1 फरवरी या जनवरी 2 है, जबकि यदि आप आईएसओ मानक का उपयोग करते हैं तो आप 2014-02-01 * को स्टोर करते हैं और यह 1 फरवरी को स्पष्ट रूप से है।

मेरा प्रश्न: एक आईएसओ मानक उपलब्ध होने पर एक प्रोग्रामर को अपना निर्माण कब और क्यों करना चाहिए?

* स्टोर 2014-02-01, और अंतिम उपयोगकर्ता को दिखाते समय तदनुसार दिनांक प्रारूपित करें।


64
क्योंकि वे उन्हें नहीं जानते, या उनके बारे में भूल गए! आईएसओ मानकों के gazillions हैं .... क्या आप सभी ISO26262 जानते हैं?
बेसिल स्टैरनेवविच

11
आमतौर पर एक प्रोग्रामर के रूप में अनुभव की कमी आपको उन चीजों के बारे में बताती है, जिनके बारे में आपको एहसास नहीं है कि परिणाम क्या हैं। आम तौर पर एक त्वरित "मैं बस इसे इस तरह करूंगा" बिना किसी मूल्यांकन के तुरंत सोचा जाता है कि क्या इसके लिए पहले से ही कुछ मौजूद है या नहीं।
डैमकुवेल

13
इसके अलावा, कई आईएसओ मानक खोजने में आसान नहीं हैं (आमतौर पर वे बड़ी रकम खर्च करते हैं, और नवीनतम ड्राफ्ट ढूंढना इतना आसान नहीं है!)।
बेसिल स्टेयरनेविच

64
मानकों के बारे में महान बात यह है कि इसमें से चुनने के लिए बहुत सारे हैं!
जोर्ग डब्ल्यू मित्तग

5
अजीब चीजों के बीच ऐसे प्रोग्राम हैं जो एक गैर-अंग्रेजी लोकेल उपयोगकर्ता पर एक गैर-अंग्रेजी को बाध्य करते हैं ताकि वह सही ढंग से काम करने के लिए अपने स्थानीय सिस्टम-वाइड सेटिंग्स को दशमलव बिंदुओं में बदल सके। उन कार्यक्रमों की बात न करें जो काम करने से इनकार करते हैं या केवल गैर-अंग्रेजी वर्णमाला (रूसी, जापानी, ग्रीक) के तहत कचरा उत्पन्न करते हैं, अकेले आरटीएल सिस्टम (हेब्री, अरबी) दें। इसमें कुछ अज्ञानता शामिल है, मुझे लगता है।
जेन्स जी

जवाबों:


63

कभी भी दुर्भावना की विशेषता न रखें, जिसे मूर्खता द्वारा पर्याप्त रूप से समझाया गया हो। - रॉबर्ट जे Hanlon

वह, और संचार की कमी।

इसलिए, यह एंटी-आईएसओ सेंटीमेंट की साजिश नहीं है, जो लोगों को लगता है कि "मुझे पता है, मैं जीबी के बजाय यूके का उपयोग करूंगा", और न ही यह झुकाव है कि "वे बेहतर जानते हैं", या यहां तक ​​कि एक समझ है कि मानक अच्छा नहीं है । यह पूरी तरह से होगा क्योंकि वे सिर्फ यह नहीं जानते कि यह वहां है, और उन्हें इसका उपयोग करना चाहिए।

मेरा मतलब है, कुछ लोगों के लिए, अगर यह Visual Studio में बंडल नहीं है, तो यह मौजूद नहीं हो सकता है। कुछ अन्य लोगों के लिए, हो सकता है कि वे अभी पूरा सेट नहीं चाहते हैं या निश्चित सूची प्राप्त करना बहुत मुश्किल है, इसलिए वे अपनी तत्काल स्थिति को हल करने के लिए अपना उप-सेट बनाते हैं। दूसरों के लिए, डिफ़ॉल्ट वह है जो उपयोग किया जाता है - इसलिए दिनांक स्वरूपण "आईएसओ, या यहां तक ​​कि देश के लोकल में स्वरूपित" नहीं है, यह "जो कुछ भी निकलता है उसमें स्वरूपित" है और यदि यह उन पर सूट करता है, तो यह काम किया जाता है (यह आमतौर पर एक है अमेरिकी प्रोग्रामर की आलोचना)।


20
यह मदद नहीं करता है कि आईएसओ मानकों का एक बहुत महंगा है और / या मुश्किल से प्राप्त कर रहे हैं ... भले ही आप बुरी तरह से करना चाहते हैं!
हेल्टनबिकर

yyyy-mm-dd ... महंगा नहीं है
आधा

11
@ कार्यप्रवाह: खरीद के लिए महंगा, कम्प्यूटेशनल संसाधनों में महंगा नहीं है। गंभीरता से, उनके स्टोर को ब्राउज़ करें । आप फ़्लोटिंग-पॉइंट मानक चाहते हैं? वह 178 फ़्रैंक होगा।
user2357112

32

जब मैं रूबी में कार्यक्रम करता हूं, तो मैं आमतौर पर आईएसओ रूबी मानक की उपेक्षा करता हूं। क्यों? क्योंकि यह अविश्वसनीय रूप से प्रतिबंधक है! आईएसओ रूबी रूबी 1.8 और रूबी 1.9 के प्रतिच्छेदन का एक न्यूनतम उपसमूह है। रूबी का वर्तमान संस्करण, जो सभी रूबी कार्यान्वयनों द्वारा समर्थित है (या कम से कम बहुत जल्द होगा) रूबी 2.1 है, और इसमें कई विशेषताएं हैं जो प्रोग्रामिंग को आसान बनाती हैं। आईएसओ रूबी में प्रोग्रामिंग एक पीआईटीए है।

जब मैं C # में प्रोग्राम करता हूं, तो मैं ISO C # को भी नजरअंदाज कर देता हूं, जो C # 2.0 का सबसेट है (और इससे भी महत्वपूर्ण बात यह है कि ISO क्लास लाइब्रेरी .NET BCL का एक बहुत छोटा सबसेट है), और इसके बजाय मैं C # 5.0 में प्रोग्राम करता हूं और मैं डॉन आईएसओ सीएलआई में निर्दिष्ट केवल पुस्तकालयों का उपयोग करने के लिए खुद को प्रतिबंधित नहीं करता हूं, इसके बजाय मैं .NET 4.5.2 और मोनो 3.4.0 में उपलब्ध पुस्तकालयों के सामान्य सबसेट का उपयोग करता हूं।

और वेब डिज़ाइन करते समय, मैं आईएसओ HTML पर HTML5 का उपयोग करना बहुत पसंद करता हूं (जो कि HTML 4.01 स्ट्रिक्ट का एक छोटा सबसेट है), फिर से, क्योंकि HTML5 HTML के एक प्राचीन संस्करण के प्रतिबंधित सबसेट की तुलना में बहुत अधिक सुविधा संपन्न है।

इसलिए, आईएसओ मानकों की अनदेखी करने के अच्छे कारण हैं।


9
यह निर्भर करता है, सी, सी ++, फोरट्रान के साथ ... स्थिति बहुत अलग है।
व्लादिमीर एफ

1
यह "अनदेखा करना" जैसा कम लगता है, जैसा कि प्रश्न का इरादा है, और अधिक "एक उपकरण चुनना जो आपको चाहिए"। यदि आपको C # 5.0 विशेषताओं की आवश्यकता है, तो ISO C # का उपयोग करने के लिए यह अधिक समझ में नहीं आता है कि यह ISO C, या ISO Fortran का उपयोग करेगा; यह केवल वह उपकरण नहीं है जो आपने मांगा था, और आईएसओ के पास एक समकक्ष नहीं है। आपके उदाहरण में अभी भी अच्छी तरह से परिभाषित मानकों से चिपके रहना शामिल है, न कि केवल आईएसओ वाले।
लेहशेंको

3
@ लुशेंको मैं असहमत; ओपी लगता है कि आपको हमेशा आईएसओ मानकों, अवधि का पालन करना चाहिए। इस "चाहिए" के लिए एक ब्रेज़ेन प्रतिसाद के लिए +1।
djechlin

3
सभी अच्छी तरह से और अच्छा है, लेकिन मुझे लगता है कि सवाल वास्तव में डेटा प्रतिनिधित्व के लिए आईएसओ मानकों के बारे में बात कर रहा था, न कि प्रोग्रामिंग भाषाओं के लिए आईएसओ मानक।
16:25

4
कुछ लोगों का तर्क है कि (कुछ) आईएसओ मानक "कमेटी द्वारा डिज़ाइन" विरोधी पैटर्न का एक आदर्श उदाहरण हैं ...
हेल्टनबिकर

22

आपके उदाहरण के अनुसार, "GB" यूनाइटेड किंगडम का देश कोड है। हालांकि, "यूके" एक समय में मार्क (यूएस लाइब्रेरी ऑफ कांग्रेस) मानक कोड था, हालांकि मेरा मानना ​​है कि यह पदावनत है। और IANA .ukयूनाइटेड किंगडम के लिए शीर्ष-स्तरीय डोमेन के लिए उपयोग करता है ।

इसलिए, यदि कोई आईएसओ मानक के अनुरूप नहीं है, तो इसका मतलब यह नहीं है कि कोई मानक उपयोग नहीं किया जा रहा है; इसका सीधा मतलब यह हो सकता है कि एक अलग मानक का उपयोग किया जा रहा है। (जैसा कि @ Jörg ने एक टिप्पणी में उल्लेख किया है, मानकों के बारे में अच्छी बात यह है कि इसमें से चुनने के लिए बहुत सारे हैं।) किस मामले में यह प्रश्न वास्तव में बन जाता है कि दिए गए समस्या डोमेन, पर्यावरण, आदि के लिए कौन सा मानक सबसे उपयुक्त होगा ?

उस सवाल के जवाब शायद काफी हद तक राय आधारित होंगे और जल्दी से एक "धार्मिक" बहस में बदल जाएंगे। लेकिन आईएसओ मानक अनुरूपता हमेशा सबसे अच्छा जवाब नहीं है। उदाहरण के लिए, यदि सॉफ़्टवेयर का एक टुकड़ा लाइब्रेरी डेटाबेस के साथ इंटरफ़ेस करने की आवश्यकता है, तो MARC मानक आईएसओ से अधिक उपयुक्त विकल्प हो सकते हैं। यदि आपके संगठन का अधिकांश सॉफ्टवेयर चीजों को एक निश्चित तरीके से करता है, तो आप कम से कम अल्पावधि में, उस दृष्टिकोण से चिपक सकते हैं - यह आपके संगठन का "मानक" है, सब के बाद।


इसके अलावा, मानक विकसित / बदलते हैं। कल जो कंफर्टेबल था वह आज नहीं हो सकता।


और, जबकि मैं आपके द्वारा इंगित किए गए मुद्दों के कारण के रूप में अज्ञानता और / या सुस्ती का शासन नहीं करना चाहूंगा ... डेवलपर के पास उन्हें संबोधित करने के लिए पर्याप्त समय नहीं हो सकता है।


15

आईएसओ मानक का अनुपालन हमेशा एक लागत-मुक्त गतिविधि नहीं है। यदि किसी विशेष मानक को पहले से उपयोग किए जा रहे टूलकिट में लागू नहीं किया गया है, तो एक प्रोग्रामर को एक आवश्यक विकल्प का सामना करना पड़ता है: क्या यह अब इसे ठीक से लागू करने के लिए सस्ता है, या मानक को लागू नहीं करना है और बाद में रूपांतरण से निपटना है?

यह कहना आसान है "हे, आपको हमेशा मानक लागू करना चाहिए", लेकिन हर चीज की एक लागत होती है। और कुछ अच्छे कारण हैं जो एक प्रोग्रामर आईएसओ मानक को लागू नहीं करना चाहते हैं।

  • ग्राहक एक मालिकाना या गैर-आईएसओ मानक का पालन कर सकता है। ग्राहक के लिए मानक से बेहतर है कि ग्राहक जो चाहता है और आपकी भाषा की आवश्यकता है उसके अलावा एक अतिरिक्त कार्यान्वयन को छिपाकर अपने उत्तराधिकारी के लिए अनपेक्षित सिरदर्द छोड़ने की अपेक्षा कर रहा है।
  • मौजूदा डेटा का एक बड़ा सौदा हो सकता है, और एक रूपांतरण या प्रारूप-विराम अभी तक संभव नहीं हो सकता है। यदि आपके पास बीस साल के ग्राहक संपर्क और अनुबंध स्थानीय तारीख-समय के साथ हैं, तो आप जरूरी नहीं कि उन सभी लाखों-करोड़ों क्षेत्रों को आईएसओ मानक तिथियों में बदलना चाहते हैं जब तक कि आप इसे सही नहीं कर सकते।
  • मानक का पालन करने से लाभ प्रदान करने की तुलना में अधिक लागत लगाई जा सकती है। यदि आप संयुक्त राज्य अमेरिका में पूरी तरह से प्रविष्टियों के साथ काम कर रहे हैं, उदाहरण के लिए, पाँच-वर्ण ISO-3166-2 कोड (US-NY) मानक यूएस पोस्टल कोड (NY) पर तीन अनावश्यक अक्षर हैं।

1
चुस्त प्रक्रिया एक तरफ, यह किसी भी सुविधा को शामिल करने के लिए हमेशा सस्ता है - आईएसओ मानक सहित - डिजाइन / विनिर्देश चरण के दौरान, कार्यान्वयन / रखरखाव चरण के दौरान से, क्योंकि डिज़ाइन चरण केवल 10% काम का प्रतिनिधित्व करता है। यह कम रिटर्न के कानून का उलटा है - उत्पादन में दोष की पहचान करने और उसे ठीक करने के समान, यूनिट परीक्षण या स्वीकृति परीक्षण के परिणामस्वरूप पाए जाने पर 10x से अधिक खर्च हो सकता है। आप आईएसओ मानक का उपयोग नहीं करने के लिए एक ठोस कारण है तो सब पर , यह ठीक है; यदि आप कहते हैं कि आप इसे बाद में लागू करेंगे, तो आप झूठ बोल रहे हैं।
22:25 पर आरोहण

@ चेतावनी: क्या आपको लगता है कि मुझे यह स्पष्ट करना चाहिए कि "रूपांतरण" से मेरा मतलब एक आंतरिक फ़ाइल रूपांतरण था, बजाय एक आंतरिक पुनर्लेखन के?
डगएम

यदि आपका यही मतलब है, तो निश्चित रूप से मैं स्पष्ट करूंगा। यह आम तौर पर इतना आसान नहीं है, क्योंकि आईएसओ फ़ाइल प्रकारों की तुलना में डेटा प्रकारों के लिए अधिक मानकों को परिभाषित करता है, और कई अगर अधिकांश डेवलपर्स उन अनुप्रयोगों के साथ सौदा नहीं करते हैं जो दस्तावेजों या "फाइलों" के साथ सौदा नहीं करते हैं। यदि, उदाहरण के लिए, आप डेटाबेस में एक गैर-आईएसओ दिनांक या देश कोड संग्रहीत करते हैं (और नहीं संग्रहीत संबंधित आईएसओ तिथि या देश कोड को संग्रहीत ), तो सड़क के नीचे रूपांतरण की लागत बहुत अधिक होने वाली है। दूसरी ओर, यदि आप केवल कुछ उद्योग-विशिष्ट फ़ाइल प्रकारों को आयात करने के बारे में बात कर रहे हैं, तो निश्चित रूप से, जब भी आप ऐसा कर सकते हैं।
Aaronaught

+1 "... आप जरूरी नहीं कि उन सभी लाखों-करोड़ों क्षेत्रों को बदलना चाहते हैं ... जब तक आप इसे सही नहीं कर सकते।" बिल्कुल सही।
डेविड

14

अनुभवहीन प्रोग्रामर / डेटाबेस डिजाइनरों के मामले में , यह न जाने के कारण है। वे पहिया को फिर से मजबूत करने के लिए करते हैं क्योंकि वे उद्योगों में फैले लोगों के एक समूह को नहीं जानते हैं, पहले से ही इस मुद्दे पर चर्चा की और सभी द्वारा अनुमोदित एक मानक के साथ आए, जिन्होंने भाग लिया, अक्सर बहुत लंबी चर्चा, संशोधन, आदि के बाद हाल ही में एक सहकर्मी। जब मैंने उसे बताया कि क्या एक दिया गया सप्ताह एक साल का आखिरी सप्ताह माना जाता है या अगले साल का पहला ( ISO 8601 )। उन्हें विश्वास नहीं था कि कुछ विशिष्ट के बारे में एक मानक अस्तित्व में है। मैंने उसे बताया कि उस मानक पर निर्भर कई अनुप्रयोगों की शुद्धता।

अनुभवी प्रोग्रामर / डेटाबेस डिजाइनरों के मामले में , यह "बेहतर जानने" के कारण अवहेलना है , न कि आविष्कारित-यहां सिंड्रोम, और / या भव्यता। वे आईएसओ या किसी भी अन्य मानक निकायों पर भरोसा नहीं करते क्योंकि वे मानते हैं कि आईएसओ कोड "पर्याप्त स्थिर नहीं" है , जिसका अर्थ है कि यह किसी दिन बदल जाएगा। इसलिए वे अपना स्वयं का आविष्कार, यहां-वहां या ऑटो इंक्रीमेंट किए गए कोड / आइडेंटिफायर को इंटरऑपरेबिलिटी में बाधा बनाते हैं, जिसकी वे अवहेलना भी करते हैं। इसी तरह के प्रश्न को देखें , अलबाइट डेटाबेस-डिज़ाइन झुका हुआ। वे कारण जैसे:

मैं जरूरी नहीं चाहता कि मेरा डेटाबेस डिजाइन तीसरे पक्ष (IATA, ISO) के एक समूह पर निर्भर हो, चाहे उनका मानक कितना भी स्थिर क्यों न हो। या, मैं किसी विशेष मानक पर बिल्कुल भी निर्भर नहीं रहना चाहूंगा।

यहाँ छवि विवरण दर्ज करें

अजीब तरह से जो मानक की अवहेलना करते हैं वे मानक यूएसबी पोर्ट का उपयोग करते हैं, मानक आकार की डीवीडी और ब्लूरेस खरीदते हैं और मानकों के अनुरूप टायर वाले कारों को चलाते हैं।


12
-1 आपके अनुभवी, एंटी-आईएसओ प्रोग्रामर के कैरिकेचर के लिए।
djechlin

4
@djechlin उद्धरणों में वाक्यांशों से जुड़े प्रश्न में वास्तविक उत्तरों से शाब्दिक हैं। तुम भी पृष्ठ में खोज कर सकते हैं देखने के लिए उन असली राय हैं। इसके अलावा सभी अनुभवी प्रोग्रामर मानकों से नफरत नहीं करते।
ट्यूलेंस कोर्डोवा

2
@djechlin मेरे जवाब में एक जुड़ा हुआ प्रश्न है, "इसी तरह का प्रश्न देखें" के लिए देखें। "प्रश्न" शब्द की एक कड़ी है। वहां आप उद्धरणों में सटीक वाक्यांशों के लिए खोज कर सकते हैं।
ट्यूलेंस कोर्डोवा

2
@djechlin लिंक उत्तर में है, सवाल नहीं, यहाँ आपके पास है: प्रोग्रामर.स्टैकएक्सचेंज.
com

5
दूसरी तरफ, जिस व्यक्ति ने यह उत्तर लिखा है वह लिंक किए गए प्रश्न को गलत तरीके से प्रस्तुत कर रहा है; समस्या मानकों का उपयोग नहीं करने के लिए लोगों के साथ नहीं था , लेकिन एक प्राथमिक कुंजी के रूप में एक विशेष मानक की स्थिरता पर निर्भर करता है । अधिकांश अनुभवी डेटाबेस डिजाइनर आज आपको "प्राकृतिक कुंजी", अवधि से दूर करने की कोशिश करेंगे, क्योंकि वे लगभग अनिवार्य रूप से कम प्राकृतिक होने की तुलना में आप मूल रूप से ग्रहण करते हैं। यह केवल तार्किक डेटा से भौतिक डेटाबेस डिज़ाइन को डिकूप करने के लिए एक तर्क है - किसी ने भी मानकों का उपयोग नहीं करने के लिए कहा।
Aaronaught

10

ठीक है, लोग आईएसओ मानकों की अनदेखी करते हैं: उदाहरण के लिए, आपने लिखा था

यदि आप आईएसओ मानक का उपयोग करते हैं तो आप 20140201 * को स्टोर करते हैं और यह 1 फरवरी को स्पष्ट रूप से है।

लेकिन पूरी तरह से ISO8601-अनुरूप प्रतिपादन वास्तव में 2014-02-01 है । ( xkcd 1179 भी देखें )


7
ISO8601 मानक पूर्ण कैलेंडर तिथि अभ्यावेदन के लिए YYYY-MM-DD और YYYYMMDD दोनों स्वरूपों की अनुमति देता है।
पीटर बी

1
वास्तव में; इसलिए मेरा लेखन "पूरी तरह से आज्ञाकारी"। 20140201 मानक में "मूल" प्रारूप है।
क्लेमेंट

8
आईएसओ बुनियादी और विस्तारित प्रारूप की अनुमति देता है, ये दोनों पूरी तरह से अनुपालन हैं।
पीटर बी

10
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.क्लासिक
वर्नरसीडी

8

कारणों में से एक यह है कि एप्लिकेशन डोमेन और उपयोगकर्ता इन मानकों का स्वयं उपयोग नहीं कर सकते हैं। यहां तक ​​कि जब कुछ डोमेन कुछ मानकों का उपयोग करते हैं, तो उनमें से कुछ ने आईएसओ मानकों की तुलना में अलग-अलग विकल्प बनाए होंगे, अक्सर ऐतिहासिक कारणों से।

यदि आपके उपयोगकर्ता पहले से ही "यूके" का उपयोग अपनी मौजूदा प्रक्रियाओं (1) में "यूनाइटेड किंगडम ऑफ ग्रेट ब्रिटेन और नॉर्दर्न आयरलैंड" को संदर्भित करने के लिए करते हैं, तो यह जरूरी नहीं कि उनके डेटा संरचनाओं में "जीबी" का उपयोग करने का कोई मतलब नहीं है (विशेषकर यदि आप देश से मतलब काफी "आईएसओ" देश नहीं है, उदाहरण के लिए यूके के देशों को अलग करना या चैनल द्वीप समूह के साथ सूक्ष्म अंतर होना)। बेशक, आपके पास आंतरिक भंडारण के बीच एक प्रस्तुति में मैपिंग हो सकती है, लेकिन कभी-कभी, यह शीर्ष पर थोड़ा सा है। आप प्रोग्रामिंग के लिए शायद ही कभी प्रोग्रामिंग कर रहे हैं, आपको अक्सर अपने वातावरण के अनुकूल होना होगा। (2)

आपको यह भी याद रखना होगा कि ये मानक सॉफ्टवेयर के समानांतर विकसित हुए हैं। आपको अक्सर सॉफ़्टवेयर के अन्य टुकड़ों के संदर्भ में विकसित करना होगा, जिनमें से कुछ अपूर्ण रूप से डिज़ाइन किए जा सकते हैं, जिनमें से कुछ अभी भी विरासत के निर्णयों से प्रभावित हो सकते हैं।

यहां तक ​​कि अगर आप आंतरिक डेटा भंडारण स्वरूपों को देखते हैं, तो कुछ अस्पष्टताओं को हल करना मुश्किल है। उदाहरण के लिए, जहां तक ​​मुझे पता है, एक्सेल टाइमस्टैम्प का प्रतिनिधित्व करने के लिए एक दशमलव संख्या का उपयोग करता है: यह एक पूर्णांक का उपयोग संदर्भ तिथि के बाद के दिनों की संख्या के रूप में करता है, तो उसके बाद दशमलव 24 घंटे के अंश का प्रतिनिधित्व करता है जो आपको घंटे देता है। .. समस्या यह है कि यह आपको खाता समय क्षेत्र या दिन के समय की बचत (23h या 25h एक दिन में) लेने से रोकता है, और Excel डिफ़ॉल्ट रूप से किसी भी तारीख / समय को उस आंतरिक प्रारूप में बदल देगा। आप आईएसओ प्रारूप का उपयोग करना चाहते हैं या नहीं अप्रासंगिक हो जाता है अगर सॉफ्टवेयर का एक और टुकड़ा जिसके साथ आपको काम करना है वह आपको एक विकल्प नहीं छोड़ता है।

(1) मेरा मतलब यहाँ "प्रोग्रामिंग प्रक्रियाओं" से नहीं है।

(२) मुझसे यह न पूछें कि लोग अपने दैनिक जीवन में उन मानकों का उपयोग क्यों नहीं करते हैं। मेरा मतलब है कि YYYYmmdd स्पष्ट है, dd / mm / YYYY स्पष्ट है, लेकिन मिमी, dd / YYYY जैसे मध्यम, छोटे, बड़े आदेश के साथ एक तारीख का आदेश देना, कि बस समझ में नहीं आता है :-)।


1
हा! तुम्हें पता है क्या मतलब नहीं है? कॉमस जहां दशमलव होना चाहिए! ;)
डार्क वाटर

@ Darkwater23 हा, मुझे कोई आपत्ति नहीं है कि किसी भी तरह से, यह सिर्फ एक सम्मेलन है और इसे समझने की आवश्यकता नहीं है। यह सिर्फ इतना है कि मैंने हमेशा पाया है कि mm / dd / YYYY को तर्क की कमी पूरी तरह से थी, इसलिए टाइमस्टैम्प के लिए mm-MM-dd-HH-YYYY तक नहीं जाना चाहिए;; लेकिन हे, मैं मानता हूँ, यह सिर्फ तरीका है यह है, इसलिए हमें इसके साथ रहना होगा।
ब्रूनो

2
@ डार्क वाटर 23 वास्तव में, एक आईएसओ मानक कीबोर्ड पर दशमलव विभाजक के लिए एक अजीब यूनिकोड प्रतीक (यह :) का उपयोग करता है , और मुझे लगा कि सादा टिक मार्क ( ') अंक समूह के लिए भी मानकीकृत थे (हालांकि अब मुझे यह नहीं मिल सकता है)
इजाक

+1 एक और कारण बताते हुए कि दिन के समय की बचत समय की बर्बादी है।
ctrl-alt-delor-

1
@richard मुझे जरूरी नहीं है कि डीएसटी किसी भी तरह से मन करे, लेकिन निश्चित रूप से प्रोग्रामर को अपने टाइमस्टैम्प को यथासंभव समय पर जानकारी के साथ स्टोर करने का लक्ष्य रखना चाहिए । किसी भी समय कई क्षेत्रों (डीएसटी के स्वतंत्र रूप से) में उपयोग किए जाने वाले आवेदन के लिए यह असामान्य नहीं है, यह सुनिश्चित करते हुए कि आप अस्पष्टता के लिए बहुत कम जगह छोड़ते हैं जब आप एक टाइम स्टैंप को प्रारंभिक डिजाइन का हिस्सा होना चाहिए। (यह हमेशा लागू नहीं हो सकता है, लेकिन संदेह में, यह हमेशा इसे ध्यान में रखने लायक है।) बेशक, यह एक जटिल समस्या है (उदाहरण के लिए, सिर्फ +01 घंटे नहीं, लेकिन उपयोग के आधार पर, स्थानीयता भी मायने रख सकती है)।
ब्रूनो

8

मैं आईएसओ 3166-1 अल्फा -2 का उपयोग क्यों नहीं करूंगा देश कोड का ?

क्योंकि मैं STANAG 1059 का उपयोग करता हूं देश कोड का ... और उस यूके में यूनाइटेड किंगडम के लिए कोड है (आईएसओ 313-1-1 के अनुसार जीबी के बजाय)।

वैकल्पिक रूप से मैं FIPS का उपयोग कर सकता हूं देश कोड का - फिर ब्रिटेन यूनाइटेड किंगडम के लिए देश कोड है।

कई मानक (आईएसओ और गैर-आईएसओ) हैं और कभी-कभी एक विशेष डोमेन एक मानक का उपयोग करता है / मांग करता है जो आईएसओ मानक के साथ असंगत है।


7

20140201 का भंडारण बिल्कुल भी नहीं है। केवल जब आप ज्ञान को शामिल करते हैं जो आईएसओ मानक का पालन कर रहा है तो यह अस्पष्ट हो जाता है। वही 01/02/2014 के लिए जाता है: जब आप इस ज्ञान को शामिल करते हैं कि प्रारूप mm / dd / yyyy है तो यह भी पूरी तरह से अस्पष्ट है।

जब तक एप्लिकेशन को अन्य एप्लिकेशन के साथ इंटरफ़ेस नहीं करना पड़ता है, तब तक कोई भी अच्छी तरह से प्रलेखित मानक ठीक काम कर सकता है।

मनुष्यों के लिए जो आसान है (मैं 1-2-2014 का उपयोग करता हूं) और कंप्यूटर (जो आईएसओ के बजाय एक द्विआधारी प्रतिनिधित्व के साथ भी बेहतर होगा) के बीच एक व्यापार है। नौसिखिए प्रोग्रामर उन चीजों से चिपके रहते हैं जिन्हें वे आसानी से समझ सकते हैं, अधिक अनुभव वाले प्रोग्रामर कंप्यूटर-उन्मुख भंडारण के फायदे देखने लगते हैं।


4
माना। यदि मैं अंतर्राष्ट्रीय उपभोग के लिए आवेदन लिख रहा हूं तो मुझे आईएसओ से अधिक चिंता होगी। मध्य अमेरिका के लिए मेरे ऐप्स को ओवरहेड या प्रतिबंधों की आवश्यकता नहीं है।
डार्क वाटर

4
"जब तक एप्लिकेशन को अन्य एप्लिकेशन के साथ इंटरफ़ेस करने की आवश्यकता नहीं है" लिखकर आपने आईएसओ मानक का उपयोग करने का एक मजबूत कारण दिया है।
ट्यूलेंस कोरडोवा

5
आपकी प्रोफ़ाइल आपके स्थान को सूचीबद्ध नहीं करती है, इसलिए मुझे नहीं पता कि आपकी नमूना तिथि जनवरी या फरवरी में है।
djechlin

6
-1 अन्य अनुप्रयोगों के साथ इंटरफेस नहीं होगा संभालने के लिए। यह संपूर्ण प्रोग्रामिंग उद्योग के विपरीत है।
djechlin

18
@ जेफ: मैंने कभी भी ऐसा नहीं देखा है कि किसी भी उद्देश्य के लिए YYYYDDMM के रूप में कोड की गई तारीख का दावा किया जा सके। क्या तुम?
सुपरकैट

5

अब तक नहीं उठाया गया एक बिंदु अंतर्राष्ट्रीय मानकों की सांस्कृतिक उपयुक्तता है।

माप के लिए अंतरराष्ट्रीय मानक पर विचार करें। संयुक्त राज्य अमेरिका के उपयोगकर्ताओं के लिए प्रस्तुत करते हैं। मुझे यकीन नहीं है कि आपके सभी अमेरिकी उपयोगकर्ता किलोमीटर, किलोग्राम और लीटर के बारे में खुश होंगे।

गौर कीजिए कि अंतरराष्ट्रीय मानक सरकारों द्वारा लिखे गए हैं। यदि स्पेन की सरकार बास्क भाषा को न पहचानने का विकल्प चुनती है तो उसे आईएसओ विनिर्देशन कैसे प्राप्त होता है? यह विशेष रूप से हाशिए के समूहों की बोलियों और creoles के साथ एक मुद्दा है।

यहां तक ​​कि देश कोड भी समस्याग्रस्त हो सकते हैं: क्या क्रीमिया को अब अपना देश कोड मिलेगा? सूत्र अंततः पाए जाते हैं (उदाहरण के लिए, "पूर्व यूगोस्लाव मैसिडोनिया गणराज्य)" लेकिन आपके आवेदन को तब तक कुछ स्टैंड-इन की आवश्यकता हो सकती है जब तक कि कूटनीति या युद्ध समाप्त न हो जाए।

विचार करें कि अंतरराष्ट्रीय मानकों को विशेष अनुप्रयोगों को ध्यान में रखते हुए लिखा गया है। ये पूरी तरह से आपके आवेदन के लायक नहीं हो सकते हैं। उदाहरण के लिए, यदि आप पत्र भेजने की दृष्टि से भाषा का भंडारण कर रहे हैं, तो आप नेत्रहीन को विशिष्ट रूप से कोडित करना चाह सकते हैं, भले ही वे बोलने में कुशल हों, कहते हैं, यूएस इंग्लिश। सांख्यिकी संगठन एक चर (उर्फ चर "मेटा डेटा") के सटीक अर्थ को निर्दिष्ट करने की आवश्यकता के बारे में अच्छी तरह से जानते हैं क्योंकि वे एक जनसंख्या जनगणना के दौरान हर संभव किनारे मामले का सामना करते हैं। डेटाबेस क्षेत्रों के लिए उस कठोरता में से कुछ अच्छी तरह से सार्थक है।

अंतिम बिंदु यह है कि इस प्रकार के विकल्पों को बनाने में आपका कार्यक्रम एक राजनीतिक बयान हो सकता है। यह वास्तविकता कोड के सबसे अच्छे के साथ गड़बड़ कर सकती है (उदाहरण के लिए, आपको एक ही भाषा के लिए कई भाषा नामों की आवश्यकता हो सकती है)।


मेरा मानना ​​है कि ज्यादातर नेत्रहीन लोग किसी को एक पत्र पढ़ने के लिए प्राप्त करने में सक्षम होंगे। ऐसा नहीं है कि आप उन्हें पत्र भेजने वाले पहले व्यक्ति (या कंपनी) होंगे।
वाइल्डकार्ड

5

मेरे अनुभव में प्रोग्रामर विभिन्न प्रकार के कारणों के लिए आईएसओ मानकों का उपयोग करने में विफल रहते हैं, उदाहरण के लिए:

  • "मुझे नहीं पता था कि एक आईएसओ मानक था" (वैध तरीके से एक बार बताए जाने पर बंद हो जाता है!)
  • "मानक अप्राप्य है (प्रति प्राप्त नहीं कर सकता / नहीं पा सकता)" (वास्तव में ??)
  • "मानक बहुत प्रतिबंधक है" (आमतौर पर अगर मानक कहता है "नहीं" तो एक अच्छा कारण है। इसे अपने और अपने ग्राहक की उपेक्षा करें!)
  • "मानक में नवीनतम कार्यक्षमता / पुस्तकालय शामिल नहीं है" (कोई भी मानक कभी भी पुस्तकालय को शामिल नहीं करता है जो आप कभी भी उन चीजों के लिए मानक का पालन करना चाहते हैं जो इसमें शामिल हैं / शामिल हैं और चीजों के लिए मानक के अनुरूप हैं। यह नहीं है)
  • "मानक लागू करने के लिए बहुत बोझिल है" (बहुत अधिक इस्तेमाल किया गया बहाना लेकिन नीचे देखें)

एकमात्र कारण जो मैं अपने कर्मचारियों से स्वीकार करता हूं, एक लंगड़ा बहाना नहीं होने के नाते, "मानक वास्तव में एक अच्छा 'फिट' नहीं है" - सबूत द्वारा समर्थित। कभी-कभी लागू आईएसओ मानक की जटिलता समस्या / समाधान के अनुपात से बाहर होती है। कभी-कभी जिस संदर्भ में आप अपने समाधान को लागू करेंगे, वह मानक द्वारा ग्रहण की गई धारणा से काफी अलग है। और कभी-कभी मानक में सुधार किया जा सकता है - यही कारण है कि प्रगति होती है।

अधिक बार नहीं हालांकि, आईएसओ मानक का उपयोग करने में विफलता को अनुभवहीनता, आलस्य या अहंकार के लिए जिम्मेदार ठहराया जा सकता है। मुझे यह कहते हुए खेद है कि अंतर्राष्ट्रीयकरण के संबंध में अंग्रेजी बोलने वाले प्रोग्रामर विशेष रूप से आलस्य के दोषी हैं और हमारे अमेरिकी सहकर्मी आईएसओ को "एक अप्रासंगिक यूरोपीय चीज" के रूप में देखते हैं (अल्पसंख्यकों के लिए माफी जो यह लागू नहीं होती है)।


5
यह जरूरी नहीं कि एक अप्रासंगिक यूरोपीय चीज है, यह एक अप्रासंगिक है जब तक आपको किसी ऐसे व्यक्ति के साथ अंतर-संचालन करने की आवश्यकता नहीं है जो उनका अनुसरण करता है। यूरोपियन कितनी बार ANSI मानकों का पालन करते हैं बिना किसी कारण के बिना हेय मानक दिखते हैं?
स्टोनमेटल

1

आईएसओ में बहुत सारे मानक हैं। जैसा कि CCITT / ITU था। इनमें से कुछ मानक "महाप्राण" मानक हैं, जबकि अन्य न्यूनतम आवश्यक कार्यक्षमता हैं। यह अक्सर स्पष्ट नहीं होता है कि कौन सा है।

मुझे 1980 के दशक में याद आया कि कुछ उपकरण विक्रेता मानक के एक सबसेट को क्यों लागू करते हैं जबकि अन्य विक्रेता एक अलग सबसेट को लागू करते हैं। जब यह सामने आया कि कुछ काम करने से पहले मानक अक्सर निर्धारित किए जाते हैं। और विक्रेता अक्सर जानबूझकर मानकों को लागू नहीं करने का चयन करते हैं ताकि वे अंतर-क्षमता में बाधा डाल सकें, जो तब उन्हें एक फायदा देता है।

इसलिए मुझे IETF RFC पसंद है। वे तब तक RFC नहीं बनते जब तक RFC के 3 स्वतंत्र कार्यान्वयन नहीं होते।


2
IETF के "किसी न किसी आम सहमति और चल रहे कोड" मॉडल को कम से कम 1995 के बाद से ही छोड़ दिया गया था। मैं उस युग में IETF में भी शामिल था और मॉडल "एक कल्पना थी कि मैंने छींक दी और एक संदर्भ कार्यान्वयन भी नहीं किया। "। यह अच्छा था जब "रनिंग कोड" मानक पूरी तरह से निर्दिष्ट प्रोटोकॉल को लागू करने और इसे अन्य कार्यान्वयन के साथ काम करने के बजाय यह अनुमान लगाने के बजाय था कि आपको जितना भी अनुमान लगाना था।
msw

1
जब मैंने IETF RFC का उपयोग करना शुरू किया, तो मैंने 1995 से पहले विकसित लोगों का अच्छी तरह से उपयोग किया। रनिंग कोड स्पेक्स सबसे अच्छे हैं। अन्यथा आप बहुत से हाथीदांत-टावर चार्टवेयर इंजीनियरों के साथ अंत करते हैं जो उन्हें चलाने की जिम्मेदारी के बिना चश्मा का सपना देखते हैं।
जय गोडसे

1

यदि मैं एक ओरेकल डेटाबेस का निर्माण कर रहा हूं, और मैं तारीखों को संग्रहीत करना चाहता हूं, तो मैं ओरेकल डेट डेटाइप का उपयोग करने जा रहा हूं। मुझे पता नहीं होगा, या परवाह नहीं है, कि ओरेकल आईएसओ मानक के अनुरूप है या नहीं। यह वास्तव में एक अलग मानक (ओरेकल वन) के लिए मेरे अनुरूप होने का मामला है और आईएसओ मानक से इतना अधिक प्रस्थान नहीं है। @ डेविड की प्रतिक्रिया देखें।

कुछ मामलों में, जब तक मुझे एहसास हुआ कि मेरे द्वारा डिज़ाइन की गई कुछ चीजों के लिए एक आईएसओ मानक था, तब तक वापस जाने और फिर से डिजाइन करने की लागत निषेधात्मक होती, या कम से कम उस तरह से देखा जाता था।

अल्पावधि में, अधिक कार्यशील कोड उपलब्ध मानकों का उपयोग करके या नए शोधों का आविष्कार करके, मौजूदा मानकों के अनुसार सावधानीपूर्वक अनुसंधान द्वारा निर्मित किया जाता है। नकारात्मक पक्ष तब होता है जब बड़े पैमाने पर एकीकरण में अंतर की आवश्यकता होती है। यह लगभग हमेशा बाद की परियोजना के संदर्भ में होता है।


1
मैं ओरेकल से परिचित नहीं हूं, लेकिन SQL सर्वर या MySQL का उपयोग करते समय मैं भी निश्चित रूप से तारीखों को संग्रहीत करते समय उनकी संबंधित डेट डेट का उपयोग करता हूं। लेकिन जब तारीखों के साथ प्रश्न लिखते हैं, तो वे दोनों yyyymmdd को अच्छी तरह से पहचानते हैं, जहां आप एक स्थानीय तारीख का उपयोग करते समय हिट या मिस करते हैं।
बी में पीट बी बी

ये एक अच्छा बिंदु है। भंडारण के लिए मानक और इंटरफ़ेस के लिए मानक भिन्न हो सकते हैं।
वाल्टर मिती
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.