|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
добрый день, коллеги помогите разобраться. Есть такой запрос, цель которого, вывести даты и соответствующие дни заданного интервала. Но, необходимо чтобы он работал с датами до нашей эры. Я пытаюсь внешним запросом убрать все даты нулевого года (которого быть не должно), но запрос ничего не выводит. Например, если ввести: 1) 28-12-0001 BC 2) 02-01-0001 AD По идее должно выводиться 6 записей, с 28.12 по 02.01 Вот сам запрос undefine start undefine finish select * from(select to_char(to_date('&&start', 'dd-mm-yyyy BC', 'nls_date_language=english') + rownum - 1, 'dd.mm.yyyy BC') my_date, to_char(to_date('&start', 'dd-mm-yyyy BC', 'nls_date_language=english') + rownum - 1, 'Day') my_day from (select 1, 2, 3 from dual group by cube(1,1,1,1,1,1,1,1,1,1)) where to_date('&start', 'dd-mm-yyyy BC', 'nls_date_language=english') + rownum - 2 < to_date('&&finish', 'dd-mm-yyyy BC', 'nls_date_language=english')) d where to_char(to_date(d.my_date, 'dd.mm.yyyy BC', 'nls_date_language=english')) <= to_date('31.12.0001 BC', 'dd.mm.yyyy BC', 'nls_date_language=english') and to_char(to_date(d.my_date, 'dd.mm.yyyy BC', 'nls_date_language=english')) >= to_date('01.01.0001 AD', 'dd.mm.yyyy BC', 'nls_date_language=english'); ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2019, 23:40 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
ag_smith, если сравнивать теплое с мягким, то, скорее всего, ничего и не получится... Вы уж или все даты в строки приводите и сравнивайте между собой строки . Или наоборот - все строки переводите в дату и сравнивайте между собой даты. А так намешали одно с другим, сдобрили всё это неявным преобразованием типов и удивляетесь полученному результату. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 04:27 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
С сотворением нашей эры не все так однозначно Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 09:02 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
-2-С сотворением нашей эры не все так однозначно Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
В Oracle Database 19.2 та же картина: Код: plsql 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 13:10 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
на всякий случай, ниже привожу работающий вариант, если вдруг кто-то столкнется с такой же задачкой undefine start undefine finish select * from(select to_date('&&start', 'dd-mm-yyyy BC', 'nls_date_language=english') + rownum - 1 my_date, to_char(to_date('&start', 'dd-mm-yyyy BC', 'nls_date_language=english') + rownum - 1, 'Day') my_day from (select 1, 2, 3 from dual group by cube(1,1,1,1,1,1,1,1,1,1)) where to_date('&start', 'dd-mm-yyyy BC', 'nls_date_language=english') + rownum - 2 < to_date('&&finish', 'dd-mm-yyyy BC', 'nls_date_language=english')) d where d.my_date <= to_date('31.12.0001 BC', 'dd.mm.yyyy BC', 'nls_date_language=english') or d.my_date >= to_date('01.01.0001 AD', 'dd.mm.yyyy BC', 'nls_date_language=english'); коллеги, еще вопрос по этому коду. как организовать защиту от выхода за максимальный интервал oracle, то есть, если одна из дат (start / finish), или обе, введены больше 29.12.9999 AD, то чтобы они приравнивались 29.12.9999 AD? В sql я не силен) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 14:29 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Неправильные результаты. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Здесь регулярно теряется один год. Нужно заводить Service Request на сайте My Oracle Support (MOS)... Проверьте, пожалуйста, что получается на менее свежих версиях базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 14:55 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
ag_smithна всякий случай, ниже привожу работающий вариант, если вдруг кто-то столкнется с такой же задачкой Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
коллеги, еще вопрос по этому коду. как организовать защиту от выхода за максимальный интервал oracle, то есть, если одна из дат (start / finish), или обе, введены больше 29.12.9999 AD, то чтобы они приравнивались 29.12.9999 AD? В sql я не силен)При оформлении кода используйте, пожалуйста, тэг SRC данного форума. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 15:06 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
SQL*PlusНужно заводить Service Request на сайте My Oracle Support (MOS)... Проверьте, пожалуйста, что получается на менее свежих версиях базы. Oracle Database 12c. Новые (/старые) грабли языка SQL Нулевой год был високосным! Bug с переходом через начало эры ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 15:53 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
SQL*PlusЗдесь регулярно теряется один год. Нужно заводить Service Request на сайте My Oracle Support (MOS)... И получишь иезуитский ответ date arithmetic используeт астрономическое нумерование годов . SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 16:01 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
SQL*PlusПроверьте, пожалуйста, что получается на менее свежих версиях базы.Отродясь так было и менять вряд решатся - могут быть системы, завязанные на юлианское число с лишними 366 днями с -4712. Предполагаю алгоритм: в арифметике участвует нулевой високосный год. Если в результате операции получается нулевой год, берется следующий год. Если после этого получается несуществующий день 29 февраля плюс-первого года, берется 1 марта. Таким образом, 365 дней нулевого года дублируется на первый год, а первое марта троируется. Разный порядок суммирования с числами менее 60 и более дает разный результат. В обратном направлении нулевой год переводится в минус-первый, но проверка на 29 февраля не делается и поведение несколько иное: Код: plsql 1. 2. 3. 4. 5.
При этом арифметика с другим несуществующим интервалом дат отрабатывает корректно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 16:10 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
-2-При этом арифметика с другим несуществующим интервалом дат отрабатывает корректно. Вы же про этот несуществующий интервал!? https://ru.wikipedia.org/wiki/Григорианский_календарь Впервые григорианский календарь был введён папой римским Григорием XIII в католических странах 4 октября 1582 года взамен прежнего юлианского: следующим днём после четверга 4 октября стала пятница 15 октября. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Ну так смогли же сделать! Отчего бы не "допилить" тот интервал, который мы здесь обсуждаем?! ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 18:04 |
|
работа с датами до наше эры
|
|||
---|---|---|---|
#18+
SQL*PlusОтчего бы не "допилить" тот интервал, который мы здесь обсуждаем?! Ну мы то за, осталось самая малость - убедить Oracle . Правда последние так лет 25 они упорно твердят - not a bug. SQL*PlusНу так смогли же сделать! Cделали да не доделали. Вводился Грегорианский каледарь в разных странах в разное время. Посему наример в java есть setGregorianChange. А в Oracle только 15 Октября 1582. Так-что работая например с российскими датaми (15 Января 1918) и с ангийскими (14 Сентября 1752) и кучей других стран обломс. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2019, 19:17 |
|
|
start [/forum/topic.php?fid=52&msg=39824920&tid=1882409]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
94ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 204ms |
0 / 0 |