Почему программисты игнорируют стандарты ISO? [закрыто]

18

Одна из вещей, с которыми я часто сталкиваюсь, это проблемы, вызванные программами, которые не соответствуют стандартам ISO.

Одним из примеров может быть не использование таблиц стран ИСО, а составление их собственных сокращений, что хорошо для Соединенных Штатов (США) или Нидерландов (Нидерланды), но идет совершенно неправильно для Соединенного Королевства (Великобритании, а не Великобритании) или Испании. (ES, а не SP) и много других стран.

В качестве другого примера, обозначения внутренней даты. Зачем кому-то хранить дату как 01/02/2014? Совершенно неясно, будет ли это 1 февраля или 2 января, тогда как, если вы используете стандарт ISO, вы просто сохраняете 2014-02-01 *, и это однозначно 1 февраля.

Мой вопрос: когда и почему программист должен создавать свои собственные конструкции при наличии стандарта ISO?

* Храните 2014-02-01 и форматируйте дату соответствующим образом, показывая ее конечному пользователю.

Питер Б
источник
64
Потому что они их не знают или забыли о них! Существует множество стандартов ISO. Вы знаете все о ISO26262?
Василий Старынкевич
11
Обычно недостаток опыта программиста заставляет вас делать то, что вы не понимаете, каковы последствия. Как правило, быстрое «я просто сделаю это так» задумывается мгновенно без какой-либо оценки того, существует ли уже что-то для этого или нет.
dammkewl
13
Кроме того, многие стандарты ISO не так легко найти (обычно они стоят больших денег, а найти последнюю версию не так просто!).
Василий Старынкевич
64
Самое замечательное в стандартах - это то, что есть из чего выбирать!
Jörg W Mittag
5
Среди самых странных вещей есть программы, которые вынуждают неанглоязычного пользователя неанглийского языкового стандарта изменять свои локальные общесистемные настройки на десятичные точки, чтобы работать правильно. Не говоря уже о программах, которые отказываются работать или просто производят мусор по неанглийским кодировкам (русский, японский, греческий), не говоря уже о системах RTL (иврит, арабский). Наверное, в этом есть какое-то невежество.
JensG

Ответы:

63

Никогда не приписывайте злости то, что адекватно объясняется глупостью. - Роберт Дж. Ханлон .

Это и отсутствие общения.

Таким образом, это не заговор анти-ISO настроений, заставляющих людей думать: «Я знаю, я буду использовать Великобританию вместо Великобритании», и это не склонность к тому, что «они знают лучше», или даже ощущение, что стандарт не годится , Это будет полностью, потому что они просто не знают, что это там, и они должны использовать это.

Я имею в виду, что для некоторых людей, если он не включен в Visual Studio , он также может не существовать. Для некоторых других, возможно, им просто не нужен полный набор, или слишком сложно получить окончательный список, поэтому они просто составляют свое собственное подмножество, чтобы решить их непосредственную ситуацию. Для других по умолчанию используется то, что используется - таким образом, форматирование даты не «отформатировано в ISO или даже в локали страны», оно «отформатировано в соответствии с тем, что выходит», и, если это им подходит, то оно выполнено (обычно это критика американских программистов).

gbjbaanb
источник
20
Не помогает то, что многие стандарты ISO стоят дорого и / или их трудно получить ... Даже если вы сильно хотите!
Хелтонбайкер
гггг-мм-дд ... не дорого
полубит
11
@halfbit: Дорогой в покупке, не дорогой в вычислительных ресурсах. Серьезно, просмотрите их магазин . Вы хотите стандарт с плавающей точкой ? Это будет 178 франков.
user2357112 поддерживает Монику
32

Когда я программирую на Ruby, я обычно всегда игнорирую стандарт ISO Ruby. Почему? Потому что это невероятно ограничительно! ISO Ruby является минимальным подмножеством пересечения Ruby 1.8 и Ruby 1.9. Текущая версия Ruby, которая поддерживается всеми реализациями Ruby (или, по крайней мере, будет очень скоро), - это Ruby 2.1, и она имеет много функций, облегчающих программирование. Программирование в ISO Ruby - это PITA.

Когда я программирую на C #, я также игнорирую ISO C #, который является подмножеством C # 2.0 (и, что более важно, библиотека классов ISO является чрезвычайно малым подмножеством .NET BCL), и вместо этого я программирую на C # 5.0, и я не не ограничиваю себя использованием только библиотек, указанных в CLI ISO, вместо этого я использую общее подмножество библиотек, доступных в .NET 4.5.2 и Mono 3.4.0.

И когда я занимаюсь веб-дизайном, я очень предпочитаю использовать HTML5 вместо ISO HTML (который является небольшим подмножеством HTML 4.01 Strict), опять же, потому что HTML5 гораздо более многофункциональн, чем ограниченное подмножество древней версии HTML.

Таким образом, есть веские причины игнорировать стандарты ISO.

Йорг Миттаг
источник
9
Это зависит от C, C ++, Fortran ... ситуация совсем другая.
Владимир Ф
1
Это похоже на «игнорирование», как задумано в вопросе, и больше похоже на «выбор инструмента, который делает то, что вам нужно». Если вам нужны функции C # 5.0, использовать ISO C # не имеет больше смысла, чем использовать ISO C или ISO Fortran; это просто не тот инструмент, о котором вы просили, и у ISO нет эквивалента. Ваш пример также все еще предполагает соблюдение четко определенных стандартов, но не стандартов ISO.
Леушенко
3
@Leushenko Я не согласен; ОП, кажется, думает, что вы всегда должны следовать стандартам ISO, и точка. +1 за наглый контрпример к этому «должен».
Джечлин
3
Все хорошо, но я думаю, что в действительности речь шла о стандартах ISO для представления данных, а не о стандартах ISO для языков программирования.
Ааронаут
4
Некоторые утверждают, что (некоторые) Стандарты ИСО являются прекрасным примером анти-паттерна "Design by Committee" ...
heltonbiker
22

Согласно вашему примеру, «GB» - это код страны для Соединенного Королевства. Тем не менее, «Великобритания» была когда-то стандартным кодом MARC (Библиотеки Конгресса США), хотя я считаю, что это устарело. И IANA использует .ukдомен верхнего уровня для Соединенного Королевства.

Так что , если что - то не соответствует стандарту ISO, это не означает , что не стандарт не используется; это может просто означать, что используется другой стандарт. (Как отметил @ Jörg в комментарии, хорошая вещь о стандартах состоит в том, что есть так много выбора.) В каком случае действительно возникает вопрос, какой стандарт будет наиболее подходящим для данной проблемной области, среды и т. Д. ?

Ответы на этот вопрос, вероятно, будут в значительной степени основаны на мнении и быстро перерастут в «религиозные» дебаты. Но соответствие стандарту ISO не всегда лучший ответ. Например, если часть программного обеспечения должна взаимодействовать с библиотечными базами данных, стандарты MARC могут быть более подходящим выбором, чем ISO. Если большая часть программного обеспечения вашей организации работает определенным образом, вы можете придерживаться этого подхода, по крайней мере, в краткосрочной перспективе - в конце концов, это «стандарт» вашей организации.


Кроме того, стандарты развиваются / меняются. То, что было вчера, не может быть сегодня.


И, хотя я не хотел бы исключать невежество и / или ленивость как причину проблем, на которые вы указываете ... разработчик может просто не иметь достаточно времени для их устранения.

Дэвид
источник
15

Соответствие стандарту ISO не всегда бесплатное мероприятие. Если какой-то конкретный стандарт еще не реализован в используемом им наборе инструментов, перед программистом встает необходимый выбор: дешевле ли сейчас правильно его реализовать или не внедрить стандарт и заниматься преобразованиями позже?

Легко сказать «эй, ты всегда должен внедрять стандарт», но все имеет свою цену. И есть несколько веских причин, по которым программист может не захотеть внедрять стандарт ISO.

  • Клиент может следовать проприетарному или нестандартному стандарту. Лучше соответствовать стандарту, которого ожидает клиент, чем оставить непредвиденные головные боли для вашего преемника, скрывая дополнительную реализацию помимо того, что клиент хочет и ваш язык требует.
  • Там может быть много существующих данных, и преобразование или разрыв формата может быть еще не осуществимым. Если у вас есть двадцать лет контактов с клиентами и контракты с местными датами, вам не обязательно менять все эти сотни миллионов полей на стандартные даты ISO, пока вы не сделаете это правильно.
  • Соблюдение стандарта может повлечь за собой более высокую стоимость, чем это дает. Например, если вы имеете дело с записями, полностью находящимися в Соединенных Штатах, пятибуквенный код ISO-3166-2 (US-NY) - это три ненужных символа по сравнению со стандартным почтовым индексом США (NY).
DougM
источник
1
Помимо гибких процессов, всегда дешевле включать какие-либо функции, включая стандарт ISO, на этапе проектирования / спецификации, чем на этапе внедрения / обслуживания, поскольку этап проектирования составляет только 10% работы. Это всего лишь инверсия закона убывающей отдачи - аналогично тому, как выявление и устранение дефекта в производстве может стоить в 10 раз больше, чем если бы он был обнаружен в результате юнит-теста или приемочного испытания. Если у вас есть твердая причина не использовать стандарт ISO на всех , это нормально; если вы говорите, что реализуете это позже, вы лжете.
Aaronaught
@Aaronaught: Как вы думаете, я должен уточнить, что под «преобразованием» я подразумевал преобразование внешнего файла, а не внутреннюю перезапись?
DougM
Если это то, что вы имели в виду, то, конечно, я бы уточнить. Обычно это не так просто, так как ISO определяет больше стандартов для типов данных, чем типов файлов, и многие, если не большинство разработчиков, имеют дело с приложениями, которые не имеют дело с документами или «файлами» как таковыми. Если, например, вы храните дату или код страны, отличные от ISO, в базе данных (и не сохраняете соответствующую дату или код страны ISO), то стоимость конвертации в будущем будет очень высокой. С другой стороны, если вы просто говорите об импорте какого-то отраслевого типа файла, тогда вы можете это делать всегда.
Aaronaught
+1 "... ты не обязательно хочешь изменить все эти сотни миллионов полей ... пока ты не сможешь сделать это правильно". Точно.
Дэвид
14

В случае неопытных программистов / разработчиков баз данных это происходит из-за незнания. Они, как правило, изобретают велосипед, потому что они не знают группу людей, охватывающих различные отрасли, которые уже обсуждали проблему и придумали стандарт, одобренный всеми, кто принимал участие, часто после очень долгих обсуждений, пересмотров и т. Д. Недавно сотрудник Я выразил недоверие, когда я сказал ему, что существует стандарт ISO, касающийся того, считается ли данная неделя последней неделей года или первой в следующем году ( ISO 8601 ). Он не верил, что существует стандарт в отношении чего-то такого особенного. Я сказал ему, что правильность многих приложений зависит от этого стандарта.

В случае опытных программистов / проектировщиков баз данных это игнорируется из-за «знания лучше» , синдрома « не изобретено здесь» и / или грандиозности. Они не доверяют ISO или любым другим стандартным органам, потому что считают, что код ISO "недостаточно стабилен" , то есть когда-нибудь он изменится. Таким образом, они создают свои собственные, изобретенные здесь или автоматически увеличенные коды / идентификаторы, препятствующие взаимодействию, которое они также игнорируют. Смотрите этот похожий вопрос , хотя дизайн базы данных склонен. Они приводят причины, такие как:

Я не обязательно хочу, чтобы дизайн моей базы данных зависел от группы сторонних производителей (IATA, ISO), независимо от того, насколько стабильны их стандарты. Или я не хочу зависеть от определенного стандарта вообще.

введите описание изображения здесь

Как ни странно, те, кто не соблюдает стандарты, используют стандартные USB-порты, покупают DVD и BluRays стандартного размера и ездят на автомобилях с шинами, которые соответствуют стандартам.

Тулаинс Кордова
источник
12
-1 за вашу карикатуру на опытных анти-ISO программистов.
джехлин
4
@djechlin Фразы в кавычках буквальные из реальных ответов в связанном вопросе. Вы можете даже искать на странице, чтобы увидеть это реальные мнения. Также не все опытные программисты ненавидят стандарты.
Тулаинс Кордова
2
@djechlin В моем ответе есть связанный вопрос, ищите «увидеть этот похожий вопрос». Слово «вопрос» имеет ссылку. Там вы можете искать точные фразы в кавычках.
Тулаинс Кордова
2
@djechlin ссылка есть в ответе, а не в вопросе, вот он у вас: programmers.stackexchange.com/questions/204340/…
Тулаинс Кордова
5
С другой стороны, человек, который написал этот ответ, искажает связанный вопрос; проблема заключалась не в людях, не желающих использовать стандарты, а в зависимости от стабильности конкретного стандарта в качестве первичного ключа . Современные опытные дизайнеры баз данных попытаются увести вас от «естественных ключей», потому что они почти неизбежно оказываются менее естественными, чем вы изначально предполагали. Это просто аргумент для отделения физической структуры базы данных от логических данных - никто не говорил, что не будет использовать стандарты вообще.
Aaronaught
10

Ну, люди склонны игнорировать стандарты ISO: например, вы написали

если вы используете стандарт ISO, вы просто сохраняете 20140201 *, и это однозначно 1 февраля.

но полностью ISO8601 совместимая цветопередача фактически 2014-02-01 . (см. также XKCD 1179 )

Клеман
источник
7
Стандарт ISO8601 допускает форматы YYYY-MM-DD и YYYYMMDD для полного представления календарной даты.
Питер Б
1
В самом деле; следовательно мое письмо "полностью соответствует". 20140201 является «базовым» форматом в стандарте.
Климент
8
ISO допускает базовый и расширенный формат, оба они полностью совместимы.
Питер Б
10
ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.классика
WernerCD
8

Одна из причин заключается в том, что домен приложения и пользователи могут сами не использовать эти стандарты. Даже когда некоторые домены используют некоторые стандарты, некоторые из них могли сделать другой выбор, нежели стандарты ISO, часто по историческим причинам.

Если ваши пользователи уже используют «Великобритания» в своих существующих процедурах (1) для обозначения «Соединенное Королевство Великобритании и Северной Ирландии», не обязательно имеет смысл использовать «ГБ» в своих структурах данных (особенно если имеется в виду, что страна не совсем страна "ISO", например, разделение наций Великобритании или тонкие различия с Нормандскими островами и т. д.). Конечно, у вас может быть отображение между внутренним хранилищем и презентацией, но иногда это немного излишне. Вы редко программируете ради программирования, вам часто приходится приспосабливаться к вашей среде. (2)

Вы также должны помнить, что эти стандарты развивались параллельно с программным обеспечением. Вам часто приходится разрабатывать в контексте других частей программного обеспечения, некоторые из которых могут быть несовершенно спроектированы, а некоторые еще могут быть затронуты устаревшими решениями.

Даже если вы посмотрите на внутренние форматы хранения данных, некоторые неоднозначности трудно решить. Например, насколько я знаю, Excel использует десятичное число для представления меток времени: в качестве числа дней с контрольной даты используется целое число, а то, что после десятичной запятой представляет собой долю от 24 часов, чтобы дать вам час. .. Проблема в том, что это не позволяет вам учитывать часовые пояса или переход на летнее время (23 часа или 25 часов в день), и Excel по умолчанию преобразует любую дату / время в этот внутренний формат. Хотите ли вы использовать формат ISO или нет, становится неактуальным, если другой программный продукт, с которым вам приходится работать, не оставляет вам выбора.

(1) Я не имею в виду «процедуры программирования» здесь.

(2) Не спрашивайте меня, почему люди не используют эти стандарты в своей повседневной жизни. Я имею в виду YYYYmmdd ясно, dd / mm / YYYY ясно, но упорядочивать дату со средним, маленьким, большим порядком детализации, как mm / dd / YYYY, это просто не имеет смысла :-).

Bruno
источник
1
Ха! Вы знаете, что не имеет смысла? Запятые, где должны быть десятичные дроби! ;)
Darkwater23
@ Darkwater23 Ха, я не возражаю против этого в любом случае, это просто соглашение, и это не должно иметь смысла. Просто я всегда обнаруживал, что мм / дд / ГГГГ, похоже, вообще не хватает логики, почему бы не пойти до мм-ММ-дд-ЧЧ-ГГГГ для отметок времени ;-) Но, эй, я согласен, это именно тот способ это так, поэтому мы должны жить с этим.
Бруно
2
@ Darkwater23 На самом деле, стандарт ISO использует странный символ Unicode (this:) для десятичного разделителя на клавиатурах , и я подумал, что обычные галочки ( ') были также стандартизированы для группировки цифр (хотя я не могу найти это сейчас)
Izkata
+1 за указание на другую причину, по которой переход на летнее время является пустой тратой времени.
Ctrl-Alt-Delor
1
@ Richard Я не обязательно возражаю против DST в любом случае, но, безусловно, программисты должны стремиться хранить свои метки времени с информацией о часовых поясах в максимально возможной степени. Нередки случаи, когда приложение используется в нескольких часовых поясах (независимо от летнего времени) в любом случае, поэтому при сохранении отметки времени вы должны оставить как можно меньше места для неоднозначности, что должно быть частью первоначального проекта. (Это может быть не всегда применимо, но, сомневаясь, это всегда стоит учитывать.) Конечно, это сложная проблема (например, не только +01 час, но и местность может иметь значение, в зависимости от использования).
Бруно
8

Почему бы мне не использовать коды стран ISO 3166-1 alpha-2 ?

Потому что я использую коды стран STANAG 1059 ... и в этом Соединенном Королевстве есть код Соединенного Королевства (вместо ГБ в соответствии с ISO 3166-1).

В качестве альтернативы я мог бы использовать коды стран FIPS - опять же, Великобритания - это код страны для Соединенного Королевства.

Существует много стандартов (ISO и не-ISO), и иногда определенный домен использует / требует стандарт, который несовместим со стандартом ISO.

mt0
источник
7

Хранение 20140201 вовсе не однозначно. Только когда вы включаете знания, которые соответствуют стандарту ISO, оно становится однозначным. То же самое относится и к 02.02.2014: когда вы включаете знание, что форматом является мм / дд / гггг, это также совершенно однозначно.

Пока приложение не должно взаимодействовать с другим приложением, любой хорошо документированный стандарт может работать так же хорошо.

Существует компромисс между тем, что легко для людей (я склонен использовать 1-2-2014) и компьютерами (кому даже лучше иметь двоичное представление вместо ISO). Начинающие программисты, как правило, придерживаются того, что им легко понять, опыт программистов начинает видеть преимущества компьютерно-ориентированного хранилища.

Джефф
источник
4
Согласовано. Я был бы более заинтересован в ISO, если бы писал заявку на международное потребление. Мои приложения для Средней Америки не требуют накладных расходов или ограничений.
Darkwater23
4
Написав «Пока приложение не должно взаимодействовать с другим приложением», вы дали вескую причину использовать стандарт ISO.
Тулаинс Кордова
5
В вашем профиле не указано ваше местоположение, поэтому я не знаю, указана ли у вас дата выборки в январе или феврале.
джечлин
6
-1 для предположения, не будет взаимодействовать с другими приложениями. Это противоречит всей индустрии программирования.
Джехлин
18
@Jeff: Я НИКОГДА не видел дату, закодированную как ГГГГДДММ, для каких-либо целей, кроме заявления о возможности такого кодирования. У тебя есть?
суперкат
5

До сих пор не затронут вопрос культурной целесообразности международных стандартов.

Рассмотрим международный стандарт для измерений. Давайте представим это пользователям в Соединенных Штатах. Я не уверен, что все ваши американские пользователи будут довольны километрами, килограммами и литрами.

Учтите, что международные стандарты написаны правительствами. Если правительство Испании решает не признавать баскский язык, то как оно получает спецификацию ISO? Это особенно актуально для диалектов и креолов маргинальных групп.

Даже коды стран могут быть проблематичными: теперь Крым получает свой собственный код страны? Формулы в конечном итоге найдены (например, «Бывшая югославская Республика Македония»), но ваше заявление может нуждаться в некоторой замене, пока дипломатия или война не закончится.

Учтите, что международные стандарты написаны с учетом конкретных приложений. Они могут не полностью соответствовать вашему приложению. Например, если вы храните язык для отправки писем, вы можете четко кодировать слепых, даже если они владеют, скажем, американским английским языком. Статистические организации хорошо осведомлены о необходимости указания точного значения переменной (так называемые «метаданные» переменной), поскольку они сталкиваются с каждым возможным крайним случаем во время переписи населения. Часть этой строгости хорошо подходит для полей базы данных.

И последнее: при выборе такого рода ваша программа может делать политическое заявление. Эта реальность может испортить самый красивый код (например, вам может потребоваться несколько названий языков для одного и того же языка).

vk5tu
источник
Я верю, что большинство слепых людей смогут заставить кого-то прочитать им письмо. Не похоже, что вы будете первым человеком (или компанией), который отправит им письмо.
подстановочный
5

По моему опыту, программисты не используют стандарты ISO по ряду заявленных причин, например:

  • «Я не знал, что существует стандарт ISO» (перестает быть веской причиной, как только вы сказали!)
  • «Стандарт недоступен (не могу найти / позволить себе копию)» (правда ??)
  • «Стандарт слишком ограничительный» (обычно, если стандарт говорит «нет», то есть веская причина. Игнорируйте его на свой страх и риск своего клиента!)
  • «Стандарт не включает новейшую функциональность / библиотеку» (ни один стандарт не включает КАЖДУЮ библиотеку, которую вы когда-либо захотите использовать, поэтому придерживайтесь стандарта для вещей, которые он включает / покрывает и соответствует стандарту для вещей что это не так)
  • «Стандарт слишком громоздок для реализации» (извините, но слишком часто, но смотрите ниже)

Единственная причина, которую я принимаю от своих сотрудников, поскольку я не являюсь слабым оправданием, заключается в том, что «стандарт действительно не подходит», подкрепленный доказательствами. Иногда сложность применяемого стандарта ИСО непропорциональна проблеме / решению. Иногда контекст, в котором вы будете реализовывать свое решение, значительно отличается от того, который предполагается стандартом. И иногда можно улучшить стандарт - так происходит прогресс.

Чаще всего отказ от использования стандарта ISO может объясняться неопытностью, ленью или высокомерием. С сожалением могу сказать, что англоязычные программисты особенно виноваты в лени в отношении интернационализации и что наши американские коллеги склонны воспринимать ISO как «неуместную европейскую вещь» (извинения меньшинству, к которому это не относится).

GI8RQI
источник
5
Это не обязательно нерелевантная европейская вещь, это не имеет значения, если вам не нужно взаимодействовать с кем-то, кто следует за ними. Как часто европейцы следуют стандартам ANSI без какой-либо причины, кроме как смотреть на стандарт?
каменная металлургия
1

ИСО имеет много стандартов. Как и МККТТ / МСЭ. Некоторые из этих стандартов являются «желательными» стандартами, а другие - минимально необходимыми функциями. Не часто понятно, что есть что.

Я помню, как в 1980-х годах спрашивали, почему некоторые поставщики оборудования внедряют одно подмножество стандарта, а другие - другое. Именно тогда выяснилось, что стандарты часто устанавливаются, прежде чем что-то работает. И поставщики часто сознательно выбирают не внедрять стандарты, чтобы они могли препятствовать взаимодействию, что затем дает им преимущество.

Вот почему мне нравятся RFC IETF. Они даже не становятся RFC, пока не появятся 3 независимых реализации RFC.

Джей Годсе
источник
2
Модель IETF с «грубым консенсусом и рабочим кодом» была заброшена, по крайней мере, еще в 1995 году. Я был слишком вовлечен в IETF в ту эпоху, и эта модель была «спецификацией, которую я выдавил, а не эталонной реализацией». ». Было приятно, когда был создан стандарт «работающего кода» вместо того, чтобы выяснить, как реализовать полностью недоопределенный протокол и заставить его работать с другими реализациями, которые должны были угадывать столько же, сколько и вы.
Msw
1
Когда я начал использовать RFC IETF, я использовал те, что были разработаны задолго до 1995 года. Характеристики работающего кода являются лучшими. В противном случае у вас будет слишком много инженеров-графиков из слоновой кости, которые придумывают спецификации, не заставляя их работать.
Джей Годсе
1

Если я создаю базу данных Oracle и хочу сохранить даты, я собираюсь использовать тип данных Oracle DATE. Я не буду знать или беспокоиться о том, соответствует ли Oracle стандарту ISO. Это на самом деле случай моего соответствия другому стандарту (Oracle) и не слишком большой отход от стандарта ISO. Смотрите ответ @ Дэвида.

В некоторых случаях, к тому времени, когда я понял, что для чего-то, что я спроектировал, был стандарт ISO, стоимость возврата и перепроектирования была бы непомерно высокой или, по крайней мере, была бы такой.

В краткосрочной перспективе больше рабочего кода создается с использованием доступных стандартов или путем изобретения новых, чем путем тщательного изучения существующих стандартов. Недостаток возникает, когда крупномасштабная интеграция требует взаимодействия. Это почти всегда происходит в контексте более позднего проекта.

Уолтер Митти
источник
1
Я не знаком с Oracle, но при использовании SQL Server или MySQL я, конечно же, использую их соответствующие типы данных при хранении дат. Но при написании запросов с датами они оба очень хорошо распознают yyyymmdd, где он попадает или пропускается при использовании даты в локали.
Питер Б
Неплохо подмечено. Стандарт для хранилища и стандарт для интерфейса могут отличаться.
Уолтер Митти,