FB 2.5, IBExpert, IBX.

В таблицах поля, содержащие дату, определены как: "DT DATE,"

В результате запроса select dt from tbl дата показывается в формате dd.mm.yyyy. Что в IBExpert, что на клиенте (IBX в Дельфи).
Еще есть представление, в котором участвует эта же таблица. Выдранная из таблицы представлением дата при запросе к нему (select * from view1) показывается в формате yyyy-mm-dd. Также, что в IBExpert, что на клиенте.
ХП для разных таблиц и дат вытаскивает дату в том же самом формате: yyyy-mm-dd.

Любопытно, отчего так?
И второе - как бы преобразовать из формата yyyy-mm-dd в формат dd.mm.yyyy на сервере?
Сейчас преобразование выглядит так (в ХП, например):


А попроще нельзя ли?

Да, эксперимент показал, что так, но чего бы ему не кастится в другом формате?

Что клиент должен отвечать за отображение я понимаю, но вопрос больше о том, есть ли встроенная функция в сервере, с помощью которой можно преобразовать дату из одного формата в другой.
Есть, к примеру, запрос, где нужно сформировать составное поле из даты и наименования.
Для такой ситуации и пригодилась бы такая функция.
Получить в запросе значение не "2014-11-01, Якутск", а "01.11.2014, Якутск".

Вам, наверное, было не нужно, а мне как раз надо.
Да и с каких пор составные поля в результатах запроса стало криминалом? (или всегда было, а я пропустил?)
Еще ситуация, в которой я бы не отказался от серверной функции преобразования даты (в строковом представлении, разумеется) из одного формата в другой, это когда на клиенте, в гриде в одной и той же колонке нужно отображать текстовое значение или дату в зависимости от условий в строке.
Но уже понятно, что функция такая из области фантазий.
Да ладно, через ХП можно.

Насчет "итога" никак не соглашусь. Предложение более чем странное.
Речь в теме идет не о способах хранения даты в базе, а отображении ее в удобоваримом для юзера виде. И только лишь.
А это можно сделать где угодно (на сервере или на клиенте) и в каком угодно формате.
Что касается изменений требований у заказчика (потребуется другой формат даты, к примеру), то в этом случае все равно придется переделывать: либо приложение, либо структуру в базе (ХП ли), либо то и другое.
Чем здесь поможет ваше предложение "иметь два поля"? Переделывать все равно придется.

Ну да, количество форматов дат ограничено по определению. 20-ти вполне хватит за глаза, особенно для моноязычных приложений.
Но тема, скорее, поднята про возможности сервера.
К примеру, в MS SQL Server есть такая фича в виде дополнительного параметра к преобразователю:
convert(varchar, Date_Fact, 104)
"104" или другое какое число как раз и управляет выходным форматом даты.
Была этакая призрачная надежда, что и разработчики FB в эту сторону взглянут.
Ну, на "нет" и суда нет. Беда мизерная - другие возможности имеются.

авторформатирование дату в строку на сервере, в фиксированный формат (любой), ведет лишь к проблемам на клиенте, и ни к чему более.
Думаю, вы немного погорячились. Для меня в этом отношении на клиенте никаких проблем никогда не возникало.
Зачем мне глядеть в настройки ОСи, если я вывожу дату так как мне (клиенту) надо, а не так как настроены региональные стандрты.
На них положись, так в иной ситуации костей не соберешь.
Да, я всегда преобразовываю дату в клиентском приложении и по-другому никогда не делал, но понадобилось в очень специфической ситуации заставить это сделать сервер.
Здесь, по правде, говорить то не о чем. Надо было лишь узнать есть такая функция в FB сервере; а нет, ну и бог с ней.