Лучший способ сохранить время недели

У меня есть ситуация, когда я хочу, чтобы пользователи могли указывать временной диапазон, где время является относительным диапазоном, существующим на данной неделе. Таким образом, пользователь может выбрать понедельник 5 вечера - вторник 1 утра. Подумайте, что это похоже на «какое время - смена работы человека».Лучший способ сохранить время недели

Моя первая реакция заключается в том, что я мог хранить «относительные» времена. Таким образом, если неделя начнется в понедельник в 00:00:00, понедельник в полдень будет обозначаться как 86400/2 = . Мне не очень нравится этот метод, потому что он затрудняет обработку часовых поясов.

Есть ли «лучший» способ для этого (или просто хороший)? Есть ли у MySQL какой-то тип данных, который имеет дело с этим конкретно?

Я отметил эти «Perl» и «MySQL», так как я буду использовать их для этого приложения, но ответ не обязательно должен быть конкретным для любого из них технически.

источник

2012-04-08 GoldenNewby

Почему бы не конвертировать 'Monday 5PM - Tuesday 1 AM' в' UTC datetime range' при запросе? – kev

Возможно, я ошибаюсь, но не будет ли «конвертированный» диапазон времени и времени UTC абсолютной датой? Я ищу, чтобы хранить способ представления «Каждый вторник с 1 вечера - 8 вечера», а не «Этот конкретный вторник с 1 вечера - 8 вечера». – GoldenNewby

вы спрашиваете, какой формат лучше всего, но вы не указали, как он будет использоваться, чтобы вы не предоставили никакой информации, с помощью которой мы можем судить о том, что лучше. Какие запросы будут изучать эти данные? – ikegami

Лучший ответ будет зависеть от того, что вы будете делать с данными по течению.

Но я бы рекомендовал избегать любых хаков и делают прямой подход (синтаксис таблицы Sybase, так как мой MySQL ржаво - извините)

CREATE TABLE weekday_ranges (
    start_dow int, -- 0-6 or 1-7 depending on what's easier downstream 
    start_hour int, -- 0-23 
    start_minute int, -- 0-59 
    -- Add seconds/micorseconds as needed 
    end_dow  int, 
    end_hour  int, 
    end_minute int 
)

Альтернативный подход заключается в хранении смещения (в секундах), с воскресенья 00:00, как начальное, так и конечное смещение. Это дает свои преимущества (например, сравнение диапазонов - это просто < и > операторы вместо сложных выражений).

источник

2012-04-08 01:28:24 DVK

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

@GoldenNewby - Он работает как запрос, но определенно более уродливый запрос-привлекательный по сравнению с подходами с смещением секунд. Где он выигрывает, не нужно вычислять «Воскресенье 00:00» эпохи # на каждую неделю как на хранение, так и на восстановление – DVK

-1

Хранение начального и конечного времени в одном поле каждого (в отличие от разбитого на части) позволит проиндексировать поле. В противном случае нет большой разницы. (Это сводится к выбору того, собраны ли части в одно значение в Perl или SQL.)

Существует действительно неразрешимая проблема с часовым поясом: у вас нет возможности дифференцировать первые 2 часа со второго 2-х часов во время переключения из ДСТ. Во входных данных просто недостаточно информации для обработки.

источник

2012-04-08 01:54:45 ikegami

Ну, моя мысль о проблеме с часовым поясом была бы в том, что 2AM всегда ссылается на второй 2AM. Я могу определить, будет ли часовой пояс на заданную неделю, также видя продолжительность недели в секундах. – GoldenNewby

@GoldenNewby, Это ничего не решает. Вы по-прежнему не имеете возможности ссылаться на первые 2 часа ночи. Теперь, возможно, вам никогда не придется, но вы еще должны сказать так много. – ikegami

@GoldenNewby, изменится ли изменение часового пояса на данной неделе, не имеет никакого отношения к вашему вопросу, поэтому я не знаю, почему вы его поднимаете. Если вы введете это в игру, вы затрудняете проблему. – ikegami

Лучший способ сохранить время недели

ответ

Смежные вопросы