Дата и время в Axapta

[Gustav]

Цитата:

Сообщение от nix0root

TO_DATE(TO_CHAR(T.DATE + (T.TIME/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS') BETWEEN
TO_DATE(TO_CHAR(TO_DATE('01.01.2010', 'DD.MM.YYYY') + (60692/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS') AND
TO_DATE(TO_CHAR(TO_DATE('22.02.2010', 'DD.MM.YYYY') + (43200/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS')

Признаться, не очень понятно присутствие здесь этих "туда-сюда" конвертаций. Вполне себе работает и гораздо более простое условие:

T.DATE + T.TIME/86400 BETWEEN
TO_DATE('01.01.2010', 'DD.MM.YYYY') + 60692/86400 AND
TO_DATE('22.02.2010', 'DD.MM.YYYY') + 43200/86400

Но вообще S.Kuskov прав и условие реализуемо в самой Аксапте:

Цитата:

Сообщение от S.Kuskov

((T.Date > fromDate) || ((T.Date == fromDate) && (T.Time >= fromTime))) &&
((T.Date < toDate) || ((T.Date == toDate) && (T.Time <= toTime)))

[kashperuk]

Цитата:

Сообщение от S.Kuskov

P.S.: А на мой вопрос (Дата и время в Axapta) есть у кого-нибудь ответ?

Поковырялся с этим вопросом. Ответ по ссылке:
http://kashperuk.blogspot.com/2010/0...s-ax-2009.html

[Ivanhoe]

На самом деле с фильтрацией все плохо .

Есть дата 08.02.2010 12:00:00. Фильтруем из формы (CTRL+F, либо правой мышкой), указывая дату - запись отображается. Открываем расширенный фильтр и видим, что, например, 08.02.2010 превратилось в "08.02.2010 00:00:00" и если мы сразу нажмем ОК, то фильтр уже сработает с условием и по времени, в итоге запись пропадет (а ведь мы ничего не поменял в фильтре)!!! Это очень неинтуитивно. Ну и еще - в расширенном фильтре по такому полю нельзя выбрать дату из календаря. MS потихоньку отказывается от расширенного фильтра?? )

Мне кажется правильнее было бы тогда уж использовать новый подход AX 2009 с ключевыми словами в критериях. Например, при фильтрации из формы чтобы критерий автоматически подставлялся как AnyTime(08.02.2010), а уже внутри скрытно для пользователя расшифровывался как "08.02.2010 00:00:00 .. 08.02.2010 23:59:59".

[kashperuk]

Цитата:

Сообщение от Ivanhoe

На самом деле с фильтрацией все плохо .

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

Функциональность выбора даты и времени в расширенном фильтре, возможно, будет добавлена в АХ6. Но пока окончательного решения не принято. Но баг в системе такой уже создан.

[lev]

Цитата:

Сообщение от S.Kuskov

Извините конечно, но я так и непонял, что такого делает этот прямой запрос, что нельзя сделать средствами аксапты?
Вы же вот это хотели получить? Или я что-то не понимаю?

((T.Date > fromDate) || ((T.Date == fromDate) && (T.Time >= fromTime))) &&
((T.Date < toDate) || ((T.Date == toDate) && (T.Time <= toTime)))

Итак, сегодня в очередной раз напоролся на сравнение периода не только с датами, но и с временем. Код приведенный выше определяет вхождение конкретной даты с конкретным временем в период (например 01.10.2010 10 : 00 входит в период с 01.10.2010 09 : 00 по 01.10.2010 18 : 00).

Мне же нужно определять вхождение периода1 в период2.
Вот конкретный пример:
Период1 = с 01.10.2010 00 : 00 по 01.10.2010 00 : 00 (понятно, что имеются ввиду одни сутки. Конечно можно сказать, что пользователь должен конечное время в периоде1 указать как 23 : 59, но пользователей много, за каждым не уследишь. Да и интуитивно, как мне кажется, человек считает сутками с 00 : 00 до 00 : 00, поэтому скорее всего рано или поздно так и поставит.)

Период2 = с 01.10.2010 09 : 00 по 01.10.2010 18 : 00

Нужно определить входит ли период2 в период1 (визуально понятно, что входит )

После раздумий получился следующий код:

select 2
            where((2.FromDate   <  1.ToDate    ||
                      (2.FromDate   == 1.ToDate    &&
                      (2.FromTime   <= 1.ToTime    ||
                       1.ToTime        == 0)))                     ||
                       1.ToDate        == dateNull())              &&
                    ((2.ToDate     >  1.FromDate  ||
                     (2.ToDate     == 1.FromDate  &&
                     (2.ToTime     >= 1.FromTime  ||
                      2.ToTime     == 0)))                     ||
                      2.ToDate     == dateNull())

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

[S.Kuskov]

Цитата:

Сообщение от lev

Вот конкретный пример:
Период1 = с 01.10.2010 00 : 00 по 01.10.2010 00 : 00 (понятно, что имеются ввиду одни сутки. Конечно можно сказать, что пользователь должен конечное время в периоде1 указать как 23 : 59, но пользователей много, за каждым не уследишь. Да и интуитивно, как мне кажется, человек считает сутками с 00 : 00 до 00 : 00, поэтому скорее всего рано или поздно так и поставит.)

Если я правильно вас понял то для правой границы периода необходимо сделать следуюшее допущение:
если время нулевое 00:00, то считаем время равным 59:59.
Так? Уточняющий вопрос. Такое допущение должно быть справедливо всегда или только если дата оконьчания совпадает с датой начала периода?
т.е. как рассматривать период [01.10.2010 00:00 - 02.10.2010 00:00]
как [01.10.2010 00:00 - 02.10.2010 00:01) или
как [01.10.2010 00:00 - 02.10.2010 59:59] или
как [01.10.2010 00:00 - 01.10.2010 59:59] ?

При такой формулировке задачи, в любом случае, я бы не стал сохранять и использовать в условии те даты, которые ввёл пользователь. Что вам мешает перед обработкой/сохранением данных скорректировать их в правильный формат?

[Atar]

Цитата:

Сообщение от lev

Период1 = с 01.10.2010 00 : 00 по 01.10.2010 00 : 00 (понятно, что имеются ввиду одни сутки.

Далеко не всем это понятно, по крайней мере без контекста . Да и ваши пользователи вряд ли имеют проблемы при вводе границ диапазонов "с 1 января года1 по 31 декабря года1", а не "с 1 января года1 до 1 января года2"...

Цитата:

Сообщение от S.Kuskov

Если я правильно вас понял то для правой границы периода необходимо сделать следуюшее допущение: если время нулевое 00:00, то считаем время равным 59:59.
Так? Уточняющий вопрос. Такое допущение должно быть справедливо всегда ...?

Подозреваю что да. Это чтобы сохранить преемственность с порядком назначения диапазонов исключительно датами (с 01.10.2010 по 01.10.2010). Но это приведет к неадекватному для "нормальных" пользователей поведению системы, когда диапазон
с 01.10.2010 10:00 по 02.10.2010 00:00
достаточно неожиданно оказывается больше, чем
с 01.10.2010 10:00 по 02.10.2010 11:11

Цитата:

Сообщение от S.Kuskov

При такой формулировке задачи, в любом случае, я бы не стал сохранять и использовать в условии те даты, которые ввёл пользователь. Что вам мешает перед обработкой/сохранением данных скорректировать их в правильный формат?

Действительно, если нерадивый пользователь введет "нулевой" диапазон, то ему сразу можно показать, что система этот диапазон воспринимает по-своему.

Более того, можно, конечно пытаться ещё и интервалы с 10:00 до 10:00 (рабочая суточная смена) пытаться автоматически воспринимать как с 10:00 по 09:59. Тоже на мой взгляд, неправильно зашивать это в глубине системы.

Ведь в случае таких вмешательств может получиться, что один отчет/запрос будет работать по явно введёному пользователем диапазону, а другой - по хитро обработанному. Не есть гуд.
Извините за флуд, не удержался.

[S.Kuskov]

Привычка дело наживное. Привыкли же все месяц вводить как 01.10.2010..31.10.2010, а не 01.10.2010..01.11.2010, чем время хуже!

[lev]

Цитата:

Сообщение от S.Kuskov

Такое допущение должно быть справедливо всегда или только если дата оконьчания совпадает с датой начала периода?

всегда

Цитата:

Сообщение от S.Kuskov

т.е. как рассматривать период [01.10.2010 00:00 - 02.10.2010 00:00]

в этом случае отработает условие:

2.FromDate   <  1.ToDate

и дальше по или не пойдет, т.е. такой случай тоже отработает корректно.
02.10.2010 00:00 - это 02.10.2010 00:00
когда пользователь устанавливает конечную дату больше чем начальную, то с указанием времени у него проблем не возникает (не спрашивайте почему, сам не знаю, но практика показывает что так оно и есть)
а вот в случае периода в рамках одних суток, случается ситуация которую описал я выше.

Про авто подстановку правильного формата тоже думал, но тогда встает вопрос, а если пользователю действительно надо будет указать "00 : 00", тогда что?

[lev]

Ещё добавлю, вопрос как раз в указании времени, а не в указании дат, с периодом дат все нормально

[S.Kuskov]

Можно попытаться отличить случай, когда пользователь вообще не вводил время потому,что оно ему не важно, и время осталось нулевым, от случая, когда пользователь намеренно ввёл 00:00.
Тип time может принимать значение -1, которое визуально отображается как "??????". Он принимает это значение при ошибке ввода. Можно использовать это значение в качестве начального, что бы потом определить корректировал его пользователь или нет.

Или вообще для ввода времени использовать текстовое поле с проверками. Тогда значение "00:00" можно считать настоящим нулём, а пустую строку - концом суток

P.S.: А можно даже свой тип сделать и лукап к нему для ввода времени