Size: a a a

Clojure — русскоговорящее сообщество

2020 January 07

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
Mike Bohdan
а вот это уже интереснее, спасибо
но это как раз редко где нужно на самом деле.
Лишь надо иметь ввиду, что не стоит большие интервалы времени мерить, как 3600 * 24 * 365
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
ну и вообще, все что привязано к календарю так считать не надо
источник

MB

Mike Bohdan in Clojure — русскоговорящее сообщество
Maxim Penzin
но это как раз редко где нужно на самом деле.
Лишь надо иметь ввиду, что не стоит большие интервалы времени мерить, как 3600 * 24 * 365
это скорее интерсно для саморазвития, не знал раньше этой особенности
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
Mike Bohdan
это скорее интерсно для саморазвития, не знал раньше этой особенности
основное, что тут надо понимать - это что есть физическое или астрономическое время, а есть человеческое календарное, и оно однозначно туда - сюда не переводится.
И еще у календарного времени есть куча других особенностей.
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
Нельзя просто так взять и сказать "у меня тут все в ЮТЦ, мне пофиг" - так не работает в определенный момент.
источник

MB

Mike Bohdan in Clojure — русскоговорящее сообщество
Maxim Penzin
Нельзя просто так взять и сказать "у меня тут все в ЮТЦ, мне пофиг" - так не работает в определенный момент.
в большинстве случаев так и делают же
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
Mike Bohdan
в большинстве случаев так и делают же
ну и потом получается как попало.
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
Там нет ничего сложного, просто надо хотя бы раз про это подумать.
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
то есть надо знать, что есть разница, между физическим и человеческим временем.
источник

ST

Sergey Trofimov in Clojure — русскоговорящее сообщество
Mike Bohdan
In [1]: import datetime as dt

In [2]: import pytz

In [3]: c = dt.datetime.now(pytz.timezone('Europe/Paris'))

In [4]: (c + dt.timedelta(days=7+2-c.weekday())).replace(hour=17, minute=45)
Out[4]: datetime.datetime(2020, 1, 15, 17, 45, 45, 428519, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>)
я запустил их пример, у меня CET

(let [d (.with (LocalDate/now) (java.time.temporal.TemporalAdjusters/next java.time.DayOfWeek/WEDNESDAY))
         ldt (.atTime d 17, 45)
         zdt (.atZone ldt (java.time.ZoneId/of "Europe/Paris"))]
     (.toLocalDateTime zdt))
=> #object[java.time.LocalDateTime 0x40a185dc "2020-01-08T17:45"]
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
у нас был проект с интревалами времени на питоне. Игрок указывал свое окно времени, а клан свое, и надо было найти пересечение минимум в час. Делали обычными < и >
источник

ST

Sergey Trofimov in Clojure — русскоговорящее сообщество
Sergey Trofimov
я запустил их пример, у меня CET

(let [d (.with (LocalDate/now) (java.time.temporal.TemporalAdjusters/next java.time.DayOfWeek/WEDNESDAY))
         ldt (.atTime d 17, 45)
         zdt (.atZone ldt (java.time.ZoneId/of "Europe/Paris"))]
     (.toLocalDateTime zdt))
=> #object[java.time.LocalDateTime 0x40a185dc "2020-01-08T17:45"]
то есть у них локальное время → следующая среда 17:45 → в Париже
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
либо в постгре есть особый тип интервалов и операции на пересечение, вхождение, строго слева\справа и тд
источник

MB

Mike Bohdan in Clojure — русскоговорящее сообщество
Sergey Trofimov
я запустил их пример, у меня CET

(let [d (.with (LocalDate/now) (java.time.temporal.TemporalAdjusters/next java.time.DayOfWeek/WEDNESDAY))
         ldt (.atTime d 17, 45)
         zdt (.atZone ldt (java.time.ZoneId/of "Europe/Paris"))]
     (.toLocalDateTime zdt))
=> #object[java.time.LocalDateTime 0x40a185dc "2020-01-08T17:45"]
да, подумал еще раз и next это таки ближайший (завтра), а не следующая неделя. Вот это еще одно подтверждение, что требования типа next wednesday не работает хотяб из-за проблемы интерпретации входных данных
источник

MB

Mike Bohdan in Clojure — русскоговорящее сообщество
Ivan Grishaev
у нас был проект с интревалами времени на питоне. Игрок указывал свое окно времени, а клан свое, и надо было найти пересечение минимум в час. Делали обычными < и >
и чем это плохой подход?
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
ничем, все норм.
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
просто храните зону пользователя и проблем не возникнет
источник

ST

Sergey Trofimov in Clojure — русскоговорящее сообщество
Mike Bohdan
да, подумал еще раз и next это таки ближайший (завтра), а не следующая неделя. Вот это еще одно подтверждение, что требования типа next wednesday не работает хотяб из-за проблемы интерпретации входных данных
а вот если запустить «завтра»
(let [now (.plusDays (LocalDate/now) 1)
         d (.with now (java.time.temporal.TemporalAdjusters/next java.time.DayOfWeek/WEDNESDAY))
         ldt (.atTime d 17, 45)
         zdt (.atZone ldt (java.time.ZoneId/of "Europe/Paris"))]
     (.toLocalDateTime zdt))
=> #object[java.time.LocalDateTime 0x25c609c "2020-01-15T17:45"]
источник

ST

Sergey Trofimov in Clojure — русскоговорящее сообщество
Ivan Grishaev
просто храните зону пользователя и проблем не возникнет
я приводил пример выше, когда проблема узнать зону пользователя (если это не смещение)
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
видимо, пропустил. Но можно же из браузера заслать
источник