ES
А что потом с этой очередью делать?
ну да тоже придется дергать и смотреть пора ли кому-то слать
А чому б таймери не юзати?
Для кожної зони свій таймер з конкретною годиною?
Size: a a a
2021 January 27
R
Конкрентнее примеры приводите
А
А чому б таймери не юзати?
Для кожної зони свій таймер з конкретною годиною?
Для кожної зони свій таймер з конкретною годиною?
Кажется это более простой вариант - тем более, что не все таймзоны представлены у пользователей. Мы на проекте так и сделали. Сгруппировать по таймзонам и назначить таймеры. Каждый пользователь получает письмо в 12 по своему времени
ES
я не вижу смещений в 13 минут или 27. поскольку они всегда кратны 15ти можно ваш крон каждые 15 мин запускать https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
R
я не вижу смещений в 13 минут или 27. поскольку они всегда кратны 15ти можно ваш крон каждые 15 мин запускать https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Какой скрипт в кроне будет, тот который вы раньше скидывали?
ES
Кажется это более простой вариант - тем более, что не все таймзоны представлены у пользователей. Мы на проекте так и сделали. Сгруппировать по таймзонам и назначить таймеры. Каждый пользователь получает письмо в 12 по своему времени
у вас видимо кроны на сервере. у нас просто Lambda функция это крон. а она поднимается и гасится после выполнения. там не поставишь setInterval()
Д
я не вижу смещений в 13 минут или 27. поскольку они всегда кратны 15ти можно ваш крон каждые 15 мин запускать https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
тут уже надо подумать, а есть ли у сударя адресанты в таких экзотических таймхонах, что бы заморачиваться над этим
ES
Какой скрипт в кроне будет, тот который вы раньше скидывали?
это пример для Postgres, если у вас другая база, то и другой скрипт но принцип аналогичный
A
тут уже надо подумать, а есть ли у сударя адресанты в таких экзотических таймхонах, что бы заморачиваться над этим
Лично я бы вообще не заморачивался б даже с 30 минутными. Все равно если пользователей много, то они все в одночасье не обработаются.
ES
ну там Австралия и Катманду с такими смешениями (45 и 30 мин) может и есть у них юзеры ХЗ
R
ну там Австралия и Катманду с такими смешениями (45 и 30 мин) может и есть у них юзеры ХЗ
Такие варианты нужно учитывать
A
Потом еще придется все эти высокоточные кроны равномерно размазывать по часам, дабы нагрузка была приемлимой.
ES
😂 UTC+05:40 Непал
А
у вас видимо кроны на сервере. у нас просто Lambda функция это крон. а она поднимается и гасится после выполнения. там не поставишь setInterval()
да, понял в чем разница
Д
Такие варианты нужно учитывать
неужели вам настолько важно что бы клиент получил письмо ровно в *:00?
A
неужели вам настолько важно что бы клиент получил письмо ровно в *:00?
Так такого никогда и не будет :). У мейлеров тоже внутри очередя и т.п.
А
но если не критична точность до минуты, то можно также запускать раз в час и брать тайзоны в диапазоне одного часа
ES
все равно их никто не читает ) эти письма
TS
😂 UTC+05:40 Непал
Предлагаю ввести универсальное атомное время, не привязанное к земле, без зон и допсекунд, а кто на него не перейдет за 2 года, всех расстрелять