Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
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 на сервере? Сейчас преобразование выглядит так (в ХП, например): Код: plsql 1. 2. А попроще нельзя ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 11:04 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08FB 2.5, IBExpert, IBX. Выдранная из таблицы представлением дата при запросе к нему (select * from view1) показывается в формате yyyy-mm-dd. .......... Любопытно, отчего так? Ну наверное кастится к строке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 11:25 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Да, эксперимент показал, что так, но чего бы ему не кастится в другом формате? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 11:37 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08А попроще нельзя ли? Отображение данных - задача клиента, а не сервера. Как твои разные клиенты отображают дату - это вопрос к их создателям и настройкам ОС, но никак не к серверу. Соответственно, преобразовывать дату из формата в формат на сервере - тоже не самая лучшая идея. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 11:55 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Что клиент должен отвечать за отображение я понимаю, но вопрос больше о том, есть ли встроенная функция в сервере, с помощью которой можно преобразовать дату из одного формата в другой. Есть, к примеру, запрос, где нужно сформировать составное поле из даты и наименования. Для такой ситуации и пригодилась бы такая функция. Получить в запросе значение не "2014-11-01, Якутск", а "01.11.2014, Якутск". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 12:04 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08Есть, к примеру, запрос, где нужно сформировать составное поле из даты и наименования. Не нужно. Сделать из двух полей одно это тоже задача клиента. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 12:07 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Вам, наверное, было не нужно, а мне как раз надо. Да и с каких пор составные поля в результатах запроса стало криминалом? (или всегда было, а я пропустил?) Еще ситуация, в которой я бы не отказался от серверной функции преобразования даты (в строковом представлении, разумеется) из одного формата в другой, это когда на клиенте, в гриде в одной и той же колонке нужно отображать текстовое значение или дату в зависимости от условий в строке. Но уже понятно, что функция такая из области фантазий. Да ладно, через ХП можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 12:33 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08) из одного формата в другой на клиенте дата отображается в том формате, который задан в настройках системы на конкретном компьютере. Уж сколько раз писали, что преобразование даты на сервере к какому-то жесткому формату может вызвать проблемы с интерпретацией этой даты на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 12:51 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08Для такой ситуации и пригодилась бы такая функция. Получить в запросе значение не "2014-11-01, Якутск", а "01.11.2014, Якутск". А если мне на клиенте понадобится совсем другой формат даты? С какого-то момента изменились требования у заказчика, к примеру. И мне придётся все старые записи обновлять, конвертируя из одного формата в другой на сервере, что не есть хорошо. Итог: это должны быть разные поля: дата и строка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 13:33 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Насчет "итога" никак не соглашусь. Предложение более чем странное. Речь в теме идет не о способах хранения даты в базе, а отображении ее в удобоваримом для юзера виде. И только лишь. А это можно сделать где угодно (на сервере или на клиенте) и в каком угодно формате. Что касается изменений требований у заказчика (потребуется другой формат даты, к примеру), то в этом случае все равно придется переделывать: либо приложение, либо структуру в базе (ХП ли), либо то и другое. Чем здесь поможет ваше предложение "иметь два поля"? Переделывать все равно придется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 14:36 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08, да, придётся. Только трудоёмкость будет разной. В случае отдельного хранения даты на сервере, мне не нужно преобразовывать старые значения полей в новые, просто на клиенте написать преобразование в новый формат. Сортировка, ключ и индекс по полю типа дата будет совсем другой (гораздо легче), чем в случае составного поля. Вообще, это моё личное мнение, я стараюсь не изменять данные в базе, потому как не я ввёл эти данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 14:55 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08, и вам уже ответили, что отображение данных - это задача клиента. Со своей стороны я понял, что вы дату собираетесь хранить в строковом виде. Если был не прав, прощу прощения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 14:59 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08Речь в теме идет не о способах хранения даты в базе, а отображении ее в удобоваримом для юзера виде. И только лишь. А это можно сделать где угодно (на сервере или на клиенте) и в каком угодно формате. Нет. Во-первых, на сервере пользователя нет, как нет и средств отображения. Во-вторых, "какой угодно формат" не прокатит - пользователь определил формат в котором хочет видеть данные при настройке своей системы. На сервере этой информации нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 15:01 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
goldmi45SAN_01_08, да, придётся. Только трудоёмкость будет разной. В случае отдельного хранения даты на сервере, мне не нужно преобразовывать старые значения полей в новые, просто на клиенте написать преобразование в новый формат. Сортировка, ключ и индекс по полю типа дата будет совсем другой (гораздо легче), чем в случае составного поля. Вообще, это моё личное мнение, я стараюсь не изменять данные в базе, потому как не я ввёл эти данные. А что кто-то говорил, что дата не хранится отдельно, или речь шла о сортировке, индексах???? зы. по поводу "просто на клиенте написать преобразование в новый формат" точно так-же просто на сервере написать преобразование в новый формат (что для меня намного удобнее, но это моё личное мнение) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 15:03 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08Что клиент должен отвечать за отображение я понимаю, но вопрос больше о том, есть ли встроенная функция в сервере, с помощью которой можно преобразовать дату из одного формата в другой. Есть, к примеру, запрос, где нужно сформировать составное поле из даты и наименования. Для такой ситуации и пригодилась бы такая функция. Получить в запросе значение не "2014-11-01, Якутск", а "01.11.2014, Якутск". Чтобы не толочь воду в ступе. Встроенной функции Format в FB на данный момент нет (как минимум до версий 2.5.Х; насчет 3.0 не в курсе). Если очень надо - можно написать свою UDF, или поискать подходящую из уже существующих. При большом желании можно даже процедуру написать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 15:27 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
miwaonline, в 3.0 тоже нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 15:35 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, Я подозревал это, но поскольку c 3.0 еще не работал плотно, а здесь ты о новых встроенных функциях вообще не упоминал (что не значит что их нет), то решил вставить ремарку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 15:47 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
miwaonline, Там изменений по большому счёту два: 1. Функция SUBSTRING может работать с регулярными выражениями. Это описано. 2. Появились гиперболические тригонометрические и обратные от них функции. Это не описано ввиду малозначимости. В LR будет конечно. Но в FB3 можно написать свою PSQL функцию для форматирования, хотя она будет работать медленней чем UDF/UDR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 16:06 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
miwaonlineПри большом желании можно даже процедуру написать. При этом важный момент, что процедуру можно делать не универсальной. Количество форматов для даты/времени порядка 20 может вполне хватить. Жёстко вбить в код через if-ы и ошибка в случае промаха. Уже кучу лет так работает. В 3.0 только вызов будет в стиле функции лаконичнее и проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 17:18 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисТам изменений по большому счёту два Понятно, спасибо. afgmПри этом важный момент, что процедуру можно делать не универсальной. Количество форматов для даты/времени порядка 20 может вполне хватить. Жёстко вбить в код через if-ы и ошибка в случае промаха. +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 18:57 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Ну да, количество форматов дат ограничено по определению. 20-ти вполне хватит за глаза, особенно для моноязычных приложений. Но тема, скорее, поднята про возможности сервера. К примеру, в MS SQL Server есть такая фича в виде дополнительного параметра к преобразователю: convert(varchar, Date_Fact, 104) "104" или другое какое число как раз и управляет выходным форматом даты. Была этакая призрачная надежда, что и разработчики FB в эту сторону взглянут. Ну, на "нет" и суда нет. Беда мизерная - другие возможности имеются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 21:11 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08Ну да, количество форматов дат ограничено по определению. 20-ти вполне хватит за глаза, особенно для моноязычных приложений. вы это, адекватны? если дата хранится на сервере как дата, то, допустим, одно и то же приложение, запущенное на двух компьютерах, с разными форматами данных в системе, покажут одну и ту же дату например как dd.mm.yyyy mm/dd/yyyy и никаких проблем при этом у приложений не будет. Вы вообще в настройки системы на тему даты заглядывали хоть раз? О чем вам и говорят, что форматирование дату в строку на сервере, в фиксированный формат (любой), ведет лишь к проблемам на клиенте, и ни к чему более. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 21:56 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
SAN_01_08, я еще добавлю - уже сколько лет известна эта "проблема", но тем не менее люди все продолжают наступать на эти грабли, причем их упорство в этом просто удивительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 21:57 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
авторформатирование дату в строку на сервере, в фиксированный формат (любой), ведет лишь к проблемам на клиенте, и ни к чему более. Думаю, вы немного погорячились. Для меня в этом отношении на клиенте никаких проблем никогда не возникало. Зачем мне глядеть в настройки ОСи, если я вывожу дату так как мне (клиенту) надо, а не так как настроены региональные стандрты. На них положись, так в иной ситуации костей не соберешь. Да, я всегда преобразовываю дату в клиентском приложении и по-другому никогда не делал, но понадобилось в очень специфической ситуации заставить это сделать сервер. Здесь, по правде, говорить то не о чем. Надо было лишь узнать есть такая функция в FB сервере; а нет, ну и бог с ней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 22:37 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
kdvSAN_01_08Ну да, количество форматов дат ограничено по определению. 20-ти вполне хватит за глаза, особенно для моноязычных приложений. вы это, адекватны? если дата хранится на сервере как дата, то, допустим, одно и то же приложение, запущенное на двух компьютерах, с разными форматами данных в системе, покажут одну и ту же дату например как dd.mm.yyyy mm/dd/yyyy и никаких проблем при этом у приложений не будет. Вы вообще в настройки системы на тему даты заглядывали хоть раз? О чем вам и говорят, что форматирование дату в строку на сервере, в фиксированный формат (любой), ведет лишь к проблемам на клиенте, и ни к чему более. И зачем столь категорично утверждать, не оставляя ни доли сомнения в правильном выборе нужного. При осознанном выборе нет с форматированием даты на сервере никаких проблем (мда, тоже категорично получилось, дабы исправиться добавлю) я так думаю. зы. Ну как-то так просим сервер Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. и что-то такое подучаем 3.02.15 03.02.15 03.02.2015 Сегодня 3-й день февраля месяца года 2015 от РХ Сегодня 3-й день Февраля месяца года 2015 от РХ Данные за февраль 2015 года ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2015, 08:20 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
m7mзы. Ну как-то так просим сервер ... и что-то такое подучаем ... хочется аналог этого? select to_char(sysdate, 'DD.MM.YY') from dual union select to_char(sysdate, 'DD.MM.YYYY') from dual union select 'Сегодня '||to_char(sysdate, 'DD')||' день, '||to_char(sysdate, 'Month')||' месяц, '||to_char(sysdate, 'YYYY')||' год от РХ' from dual union select 'Сегодня '||to_char(sysdate, 'DD')||' день, '||to_char(sysdate, 'month')||' месяц, '||to_char(sysdate, 'YYYY')||' год от РХ' from dual ЗЫ ну и на выходе 03.02.15 03.02.2015 Сегодня 03 день, Февраль месяц, 2015 год от РХ Сегодня 03 день, февраль месяц, 2015 год от РХ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2015, 08:50 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
Если очень хочется, то можно и самому написать. Для экспорта напрямую в инородные форматы использую это. Делов-то на пару минут... Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2015, 09:09 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
kdv О чем вам и говорят, что форматирование дату в строку на сервере, в фиксированный формат (любой), ведет лишь к проблемам на клиенте, и ни к чему более. Думаю речь идёт о форматировании даты при склейке с другим текстом (счета, отчёты, логи и пр.). Уж коли логика в хранимках, то и форматирование даты на сервер вполне допустимо. А вот отдельные поля надо оставлять в формате даты времени и отдавать на откуп клиенту. Если ТС хочет форматировать отдельное поле, то критика тут вполне оправдана, либо у ТС-а есть очень веские причины так поступить (невозможность модификации целевой системы отображения информации, например) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2015, 09:19 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
afgmлибо у ТС-а есть очень веские причины так поступить (невозможность модификации целевой системы отображения информации, например)судя по примерам хотения m7mСегодня 3-й день Февраля месяца года 2015 от РХ может быть система учёта ценностей музея или археологических находок, где значение поля может быть вроде "IV-V в.в. до н.э.", но тогда хранение даты как таковой для датирования возраста более чем сомнительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2015, 11:53 |
|
||
|
Преобразование даты
|
|||
|---|---|---|---|
|
#18+
roadsterafgmлибо у ТС-а есть очень веские причины так поступить (невозможность модификации целевой системы отображения информации, например)судя по примерам хотения m7mСегодня 3-й день Февраля месяца года 2015 от РХ может быть система учёта ценностей музея или археологических находок, где значение поля может быть вроде "IV-V в.в. до н.э.", но тогда хранение даты как таковой для датирования возраста более чем сомнительно. У ТС что не знаю, а у меня просто примеры реализации. По поводу "Сегодня 3-й день Февраля месяца года 2015 от РХ" ну просто захотелось похвастаться показать что эта реализация может. зы. она также понимает день недели, квартал, часы, минуты и секунды ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2015, 12:16 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1563057]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
171ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 276ms |
| total: | 557ms |

| 0 / 0 |
