Рядовой SNAFU идет в DBA

с темпоральными данными работал мало, и к финансовой сфере его лучше не подпускать.

Не имею понятия, как оно там в финансовой сфере. Что, реально, упор на работу со временем, а не тупо подряд со всем и какими-то очередями?

Что хотел сделать автор кода?
Почему это может работать не так, как хотелось?
Как это исправить?
Очевидно плохо в этом только одно — задающий вопрос.
Любая задача имеет область определения: нельзя решить бином на множестве действительных чисел при отрицательном дискриминанте, нельзя сокращать на ноль и т.д. Постановщик задачи предложил рассмотреть все варианты, кроме правильного: автор кода точно знает, что хранится в таблице и что нужно получить в результате запроса. Снафу ожидаемо слился.

Довольно давно использую формат yyyy-MM-dd [HH:mm:ss] в работе.
Для отчетов на бек энде всегда использую их, и еще небыло ни одного клиента, которого это не устроило. Даже есть пример, когда отображение в UTC сняло напряженность между регионами
Еще в далеком 96-м впервые наткнулся на то, что с датой типа 13/06/96 проблем нет. А вот с 10/06/96 — «температура за бортом» зависит от локали. До этого кроме моего компа и компа отца (настроенных абсолютно одинаково) — других не «щупал».
sshikov, я работаю с MSSQL, и в нем таймстемп содержит дату, время и таймзону. Если нужно отображать время в определенной зоне, либо откорректировать зону без изменения времени, то для этого есть соответствующие функции.

Ну тогда вот вам еще: Events — это системное представление, в котором нет поля DT… Неплохо было бы уточнить, например: FROM [dbo].[Events]

Для начала бы неплохо указать про грабли в написании даты.
Даже если в поле хранится DATE и запрос вроде бы корректный, достаточно сделать

SET DATEFORMAT YDM

и запрос превращается в тыкву.
А всего лишь надо было написать в универсальном формате, или явно его указав при конвертации из строки

SELECT * FROM Events where DT='20200203'
SELECT * FROM Events where DT= Convert(date, '2020/02/03', 111)

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

Вот и в этой статье мы видим типичную ситуацию с «Токсичным собеседованием», где главная цель задающего вопросы — надуться от собственной важности и расчесать своё и без того громадное ЧСВ.

Видимо это какая-то специфика банковской сферы. И то сказать, в Россиюшке-то банки и тюрьма рука об руку ходят, а там уж недалеко до вопросов о двух стульях. Которые, как известно, и нужны для того, чтобы новичка «опустить».

На практике, конечно, это работает не так. И даже сам автор, решая подобные задачи на практике, действовал бы не так — потому что ему нужно было бы не наполнить соискателя чувством вины, чтобы снизить ожидаемую зарплату, а решить бизнес-задачу.

Итак, задача:

>Что хотел сделать автор кода?
>Как это исправить?
>Почему это может работать не так, как хотелось?

Итак, ответ:

Гаданиями занимаются дальше по улице в палатке гадалки и чудотворицы Мадам Эвелины, Потомственной Ясновидящей. Если вы пришли ко мне с куском кода, с вопросами — наверное вы УЖЕ ЗНАЕТЕ, что работает не так, и столкнулись с какой-то ошибкой? Назовите её, мы поищем источник и будем думать, как поправить. Это в том случае, если у нас нет ни автора кода (который возможно ещё работает у нас), ни технического задания (в котором, возможно, написано, что нужно было сделать), ни представителей заказчика/бизнеса (которые, возможно, способны прямо сказать, что именно они хотят).

В копилку забавных фактов — если поставить человеку задачу в правильном виде, то есть «выбрать данные за день, если поле даты такого-то формата» — большинство людей, которые «тупят» в ответ на идиотские вопросы, напишут правильный код. Просто потому что их мозг будет занят решением конкретной и полезной задачи, а не поиском ответов на идиотские вопросы про круглые люки и способы выбраться из блендера.

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

А мне нравится задачка, возьму на заметку. Только в формате «какие проблемы/сайд-эффекты могут возникнуть, при использовании такого запроса»

Ну нельзя же так отсылку на полпути терять, персонажа-то так не в честь фазы луны назвали, а в честь хрестоматийного Situation Normal: All Fucked Up.

Ну и это, я вот вообще ни разу не специалист по DB, но я бы:

• спросил интервьюера, с какого перепугу у нас нет триггера на insert и автозаполняемого поля utc_date, которое сохранит кучу нервов, если ивенты приходят в локальных таймзонах, или с задержками
• спросил интервьюера, что за RDBMS, потому что $1 + integer '2' в постгресе, например, наверняка отработает быстрее (незначительно, но тем не менее)
• спросил интервьюера, здоров ли он вообще, если думает, что «DT станет smalldatetime или datetime2» — это изменение, которое поломает вот только этот мой избранный простенький SELECT.

Но это я, я в базах ничего не понимаю, кроме того, что они данные как-то там хранят.

Автор статьи, зачем вы мучаете людей на интервью? Попробуйте сами решить задание, сформулированное схожим с вашим форматом: есть код

UPDATE table_name SET datetime2 = SYSDATETIME()
WHERE datetime2 IS NULL;
GO

Задача: Возвращать значение обновлённого времени. Ваше решение?

Автор, а вы сами новичком не были? Когда о таких деталях узнали? До устройства на работу или вам дали шанс набраться опыта?