Про задачку с интервалами сформулируйте более формально, чтобы было понятно какими входными данными оперировать и в какой форме результат получить. С удовольствием порешаю на досуге.
Да, алгоритм-то несложен — посчитать количество рабочих дней, правильно учесть первый и последний дни, всё сложить. Осталось это выразить на SQL.
PS умножить надо на 9
Я боюсь своими комментариями дать Вам слишком много подсказок, поэтому приходится быть не слишком многословным. На моей тестовой выборке расхождения есть.
Добрый день! Для решения задачи зарегистрировался на хабре, комменты оставлять не дает.
Мое решение: with periods(id, start_time, stop_time) as (
values(1, '2019-03-29 07:00:00'::timestamp, '2019-04-08 14:00:00'::timestamp),
(2, '2019-04-10 07:00:00'::timestamp, '2019-04-10 20:00:00'::timestamp),
(3, '2019-04-11 12:00:00'::timestamp, '2019-04-12 16:00:00'::timestamp),
(4, '2018-12-28 12:00:00'::timestamp, '2019-01-16 16:00:00'::timestamp)
),
hollydays(dt) as (values ('2019-03-29'))
select p.id, start_time, stop_time, cnt work_hrs from periods
join (
select
id, count(1) cnt
from (select id, generate_series(start_time, stop_time — interval '1 hour', '1 hour') tm from periods) p
where
to_char(tm, 'hh24')::int between 10 and 19 — 1 and
extract(dow from tm) between 1 and 5 and
tm::date not in (select dt::date from hollydays)
group by id
) p on p.id = periods.id
Что-то я смотрю, что рабочие часы воспринимаются почему-то исключительно без рабочих минут. Минуты не забывайте! Я поправил исходные интервалы и ожидаемый ответ, чтобы подчеркнуть наличие минут.
Мне кажется, что удобнее задать праздники именно в CTE.
По остальным вопросам все ответы есть в условии: рабочее время с 10:00 до 19:00, что составляет девять часов; предпраздничный день является полным.
А я вот в статье разглядел, что этот самый Т2 умеет менять своё поведение извне. То есть вся новая техника эпла теперь в одном ботнете. Чужим микрофон не даёт, а своим может… И ещё может потенциально что угодно. Прискорбно.
И это только проблема так называемого jitter-а, то есть неустойчивого чтения сигнала. А есть ещё и так называемая проблема синхронизации. В стандарте CD-DA отсутствует информация о начале трека и номер этого трека в самом читаемом блоке. В цифровых CD в 2352 байт на данные остаётся 2048, остальное занято структурами, позволяющими понять, что это и правильно ли прочиталось. А в аудио-CD (которые CD-DA) идёт просто поток байтов в одну дорожку. Как на виниле. Никаких отметок, что у нас начался однатысячакакойтотам сектор нет и в помине. Поэтому драйв, когда его просят прочесть однатысячакакойтотам сектор, тщательно прицеливается и что-то читает. Иногда не одно и то же, если промахивается на несколько байт или несколько десятков-сотен байт…
Развлекался я таким под OS/2 двадцать лет назад. Уже перезабыл почти всё. Но даже на фоне моих давно забытых знаний статья автора (переводчик, надеюсь, не виноват) выглядит забористым бредом. Это уже однако тенденция, когда народ по какой-то левой документации (в данном случае к EAC) пытается понять находядщиеся в свободном доступе стандарты (в данном случае Red Book, в которой описан стандарт cd-da). Софтина конечно была знатная, но кто мешал автору почитать стандарты и не городить кучу необоснованных выводов о том, что прочиталось с диска? Не в первый раз уже встречаю, что народ вместо изучения имеющейся доступной информации начинает гадать на кофейной гуще. Неонеандертальцы какие-то.
Про задачку с интервалами сформулируйте более формально, чтобы было понятно какими входными данными оперировать и в какой форме результат получить. С удовольствием порешаю на досуге.
PS умножить надо на 9
Мое решение:
with periods(id, start_time, stop_time) as (
values(1, '2019-03-29 07:00:00'::timestamp, '2019-04-08 14:00:00'::timestamp),
(2, '2019-04-10 07:00:00'::timestamp, '2019-04-10 20:00:00'::timestamp),
(3, '2019-04-11 12:00:00'::timestamp, '2019-04-12 16:00:00'::timestamp),
(4, '2018-12-28 12:00:00'::timestamp, '2019-01-16 16:00:00'::timestamp)
),
hollydays(dt) as (values ('2019-03-29'))
select p.id, start_time, stop_time, cnt work_hrs from periods
join (
select
id, count(1) cnt
from (select id, generate_series(start_time, stop_time — interval '1 hour', '1 hour') tm from periods) p
where
to_char(tm, 'hh24')::int between 10 and 19 — 1 and
extract(dow from tm) between 1 and 5 and
tm::date not in (select dt::date from hollydays)
group by id
) p on p.id = periods.id
Почему не может? Никаким условиям не противоречит. Условия говорят, что нужно посчитать, сколько часов из интервала были рабочими.
По остальным вопросам все ответы есть в условии: рабочее время с 10:00 до 19:00, что составляет девять часов; предпраздничный день является полным.
Развлекался я таким под OS/2 двадцать лет назад. Уже перезабыл почти всё. Но даже на фоне моих давно забытых знаний статья автора (переводчик, надеюсь, не виноват) выглядит забористым бредом. Это уже однако тенденция, когда народ по какой-то левой документации (в данном случае к EAC) пытается понять находядщиеся в свободном доступе стандарты (в данном случае Red Book, в которой описан стандарт cd-da). Софтина конечно была знатная, но кто мешал автору почитать стандарты и не городить кучу необоснованных выводов о том, что прочиталось с диска? Не в первый раз уже встречаю, что народ вместо изучения имеющейся доступной информации начинает гадать на кофейной гуще. Неонеандертальцы какие-то.