Д
да. примерно это я и объяснял
Size: a a a
2021 January 25
R
знаючи таймзони ортимувачів та локальну таймзону вашого сервіса можна вирахувати локальний час, який відповідає необхідному часу отримувача і відповідно запланувати на цей час запуск нотифікацій.
Например?
DK
Например?
Наприклад необхідно відправляти повідомлення в 10:20 в таймзоні отримувача +01:00
Ваш сервіс/сервер працює в таймзоні +02:00
Відповідно вам необхідно запланувати запуск на 11:20 в таймзоні сервісу, щоб отримувачу повідомлення відправилось о 10:20
Якщо я правильно зрозумів вашу задачу
Ваш сервіс/сервер працює в таймзоні +02:00
Відповідно вам необхідно запланувати запуск на 11:20 в таймзоні сервісу, щоб отримувачу повідомлення відправилось о 10:20
Якщо я правильно зрозумів вашу задачу
R
Наприклад необхідно відправляти повідомлення в 10:20 в таймзоні отримувача +01:00
Ваш сервіс/сервер працює в таймзоні +02:00
Відповідно вам необхідно запланувати запуск на 11:20 в таймзоні сервісу, щоб отримувачу повідомлення відправилось о 10:20
Якщо я правильно зрозумів вашу задачу
Ваш сервіс/сервер працює в таймзоні +02:00
Відповідно вам необхідно запланувати запуск на 11:20 в таймзоні сервісу, щоб отримувачу повідомлення відправилось о 10:20
Якщо я правильно зрозумів вашу задачу
а если у меня 5 таймзон?
R
это ж не таймзона +01:00
IJ
а если у меня 5 таймзон?
сколько у вас таймзонов будет зависить от ваших пользователей в базе
IJ
это ж не таймзона +01:00
это таймзона в универсальном формате погуглите таймзоны и вы поймете +01:00 это разница во времени на час вперед потому что утро и вечер в разных континентах наступает в разное время
R
это таймзона в универсальном формате погуглите таймзоны и вы поймете +01:00 это разница во времени на час вперед потому что утро и вечер в разных континентах наступает в разное время
ок, как превести Europe/Kiev в такой формат?
IJ
погуглите Timezone europe/kiev. к сожалению кодировку я не помню из памяти
DK
а если у меня 5 таймзон?
аналогічно
IJ
оказывается Киев +02:00 в UTC формате
ES
это таймзона в универсальном формате погуглите таймзоны и вы поймете +01:00 это разница во времени на час вперед потому что утро и вечер в разных континентах наступает в разное время
Это НЕ таймзона а смещение
ES
У Киева два смещения но одна таймзона Europe/Kiev. И в базе нужно хранить именно в таком формате а не +02 или +03
IJ
У Киева два смещения но одна таймзона Europe/Kiev. И в базе нужно хранить именно в таком формате а не +02 или +03
да летом +03
ES
Никак не допишу у меня большая статья про таймзоны для dou недописана
DK
ок, как превести Europe/Kiev в такой формат?
NN
Наприклад необхідно відправляти повідомлення в 10:20 в таймзоні отримувача +01:00
Ваш сервіс/сервер працює в таймзоні +02:00
Відповідно вам необхідно запланувати запуск на 11:20 в таймзоні сервісу, щоб отримувачу повідомлення відправилось о 10:20
Якщо я правильно зрозумів вашу задачу
Ваш сервіс/сервер працює в таймзоні +02:00
Відповідно вам необхідно запланувати запуск на 11:20 в таймзоні сервісу, щоб отримувачу повідомлення відправилось о 10:20
Якщо я правильно зрозумів вашу задачу
сервер не должен ориентироваться на таймзону, где он находится, а рассчитывать на UTC(00:00). Например, те же базы данных хранят данные изначально в UTC
DK
сервер не должен ориентироваться на таймзону, где он находится, а рассчитывать на UTC(00:00). Например, те же базы данных хранят данные изначально в UTC
розраховувати на щось не перевіряючи - звучить не надійно
DD
Добрый день, сегодня посмотрел лекцию о middlaware.Я немного разрабатываю на nest.js стараясь сохранить многослойность архитектуры.Обычно я использую три уровня.Контроллеры-сервисы-кастомные репозитории.Зачастую возникает вопрос,которым я долго мучаю себя.В каком именно месте проверять,что ресурс соответствует данному юзеру(при этом мне нужно сделать запрос в бд). Очевидно,что уровень контроллеров, репозиториев не очень подходит.Остается только сервис, guard или validation pipe,что примено одно и тоже, потому что выполняется до контроллера(безусловно смысловая нагрузка разная и сначала срабатывает гуард).Так вот.В гуарде до контроллера делать запрос в бд,мне кажется очень сильным протеканием абстракций,а с другой стороны сервис не должен отвечать за логику доступа к ресурсу.Подскажите,где я ошибаюсь.
TS
Добрый день, сегодня посмотрел лекцию о middlaware.Я немного разрабатываю на nest.js стараясь сохранить многослойность архитектуры.Обычно я использую три уровня.Контроллеры-сервисы-кастомные репозитории.Зачастую возникает вопрос,которым я долго мучаю себя.В каком именно месте проверять,что ресурс соответствует данному юзеру(при этом мне нужно сделать запрос в бд). Очевидно,что уровень контроллеров, репозиториев не очень подходит.Остается только сервис, guard или validation pipe,что примено одно и тоже, потому что выполняется до контроллера(безусловно смысловая нагрузка разная и сначала срабатывает гуард).Так вот.В гуарде до контроллера делать запрос в бд,мне кажется очень сильным протеканием абстракций,а с другой стороны сервис не должен отвечать за логику доступа к ресурсу.Подскажите,где я ошибаюсь.
это проблема концепции rest, я все делаю по rpc, и такие проверки можно делать только в сервисе