您好，Radio SQL再次播出！ 揉捏神经节，传播假足（反之亦然？）并收听我们的引力波！
上一次，我几乎因为解析（
https://habr.com/en/post/359064/）Olympiad SQL任务而被排斥在外，据说这还远远不够。 好像标签“异常编程”和“奥运会”并不代表自己。 但是显然没有人会读取标签！ 尽管如此，我将继续以出色的编程语言SQL解析任务的主题。 因为爪子（痒）。
今天，我们面临着完全威胁生命的任务，甚至是一项务实的任务。 我遇到了这个问题，试图根据热爱用户的请求来计算SLA的性能。 最初问题的实质如下：有必要计算每个应用程序的工作时间并与我们的承诺进行比较。 一切都会好起来的，但是义务中的时间被宣布为正常工作，而从应用程序中的状态更改中，我只能得到日历。 这是一个想法！ 她在这里，任务！ 不太复杂，但也不是完全无关紧要的。 只是为了拉伸植物神经系统的中枢部分，使其更具同情心！
所以，我说条件。
它的开始和结束的日期时间指定了几个时间间隔（PostgreSQL语法中的一个示例）：
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:07:12'::timestamp), (4, '2018-12-28 12:00:00'::timestamp, '2019-01-16 16:00:00'::timestamp) )
一个SQL查询（c）中需要计算每个时间间隔的持续时间（以工作时间为单位）。 我们认为我们在周一至周五的工作日工作，工作时间始终为10:00至19:00。 此外，根据俄罗斯联邦的生产日历，有一些法定假日不是工作日，相反，由于某些假日的推迟，某些假期是工作日。 无需缩短节假日，我们认为它们已经完成。 由于假期每年不同，即由明确列出来设置，因此我们将仅限于2018年和2019年。 我确信，如有必要，可以轻松补充该解决方案。
必须从工期开始到初始工期在工作时间中增加一列。 结果如下：
id | start_time | stop_time | work_hrs
我们不检查初始数据的正确性；我们始终考虑
start_time <= stop_time 。
可以使用PostgreSQL的特殊SQL方言构造，但不能滥用。 为了使条件完全正确，我补充说查询必须在PostgreSQL 10或更高版本上执行。
一个月内将对任务进行分析。 我没有做出任何决定，因此有动力自己解决。 我们恳请-将代码放在扰流板下的注释中！
最后但并非最不重要的一点 。 如果我已经设法在Postgres Professional公司博客上发布了这篇文章，我们将使用一些公司特有的东西：对于这个问题的最有趣的解决方案，我们将免费参加
PGConf.Russia 2020 。 感兴趣的标准将是我自己的，再加上我认为有必要与之协商的同事的标准。 祝你好运
更新！ 我看到的一些东西是由于某种原因而完全没有工作时间就被认为是工作时间。 不要忘记分钟！ 我调整了初始时间间隔和预期答案，以强调分钟的可用性。
UPDATE2摘要：
https :
//habr.com/en/company/postgrespro/blog/457722/ 。