Здравствуйте, Sinclair, Вы писали:

A>>А если человек путешествует через таймзоны вслед за солнцем с устройством, адаптирующимся под таймзоны по сети? У него НГ будет в расписании столько раз, сколько он зон пересёк?
S>Конечно. Вы так говорите, как будто ни разу в новый год не летали
A>> Может я, конечно, что-то не понимаю, но передача таймзоны параметром выглядит для меня как алярм.
A>>Конкретно, мне интересно, что будет, если мы используем такую функцию в банк-клиенте для запланированных платежей, если событие случится перед вылетом и после.
S>Ну, в таком случае разработчика нужно будет пожурить на пост-мортеме.
S>Потому что
S>а) запланированные платежи должен делать банк-сервер, а не банк-клиент. Банк-клиент — штука ненадёжна. А если у него батарейка села? Или интернета нет? Пока я в самолёте летел, значит, мало того, что часовой пояс сменился, так и запланированный платёж за билайн не прошёл, и я теперь остался без связи (а, заодно, и без возможности воспользоваться банк-клиентом для ручного проведения платежа)
S>б) планирование платежей в часовом поясе устройства — не очень годная идея. Там будет часовой пояс банка.

Ну а если банк-сервер переедет в другой часовой пояс? (Не физически, понятно, а федеральным законом). Аккурат с той даты, когда платёж.

А если на клиенте я запланировал дорогую операцию не финансового, а технологического характера, и в результате попал на расходы?

А если я настроил запрос на сервис по авторассылке уникальных открыток, и ВСЕ контакты получили по паре разных якобы-от-души поздравлений, показав, что мне на самом деле на них наплевать?

В общем, если бы я проектировал такие штуки, я бы подумал о том, чтобы при создании ивента изначально учитывать таймзону и записывать абсолютное время срабатывания, а при смене таймзоны на девайсе перерасчитывать все ивенты. И таким образом гарантировать, что ежемесячно это ежемесячно, а НГ состоится один раз в году, а не 17. Для всех применений, от малозначительных до критических.

Ещё, как вариант, таймзону сделать advanced-параметром при создании ивента, и пусть ответственность будет на юзере. Или совместить этот вариант с предыдущим, сделав по дефолту значение таймзоны "current", но давая выбрать самому.

Здравствуйте, Sinclair, Вы писали:

A>>А если человек путешествует через таймзоны вслед за солнцем с устройством, адаптирующимся под таймзоны по сети? У него НГ будет в расписании столько раз, сколько он зон пересёк?
S>Конечно. Вы так говорите, как будто ни разу в новый год не летали
A>> Может я, конечно, что-то не понимаю, но передача таймзоны параметром выглядит для меня как алярм.
A>>Конкретно, мне интересно, что будет, если мы используем такую функцию в банк-клиенте для запланированных платежей, если событие случится перед вылетом и после.
S>Ну, в таком случае разработчика нужно будет пожурить на пост-мортеме.
S>Потому что
S>а) запланированные платежи должен делать банк-сервер, а не банк-клиент. Банк-клиент — штука ненадёжна. А если у него батарейка села? Или интернета нет? Пока я в самолёте летел, значит, мало того, что часовой пояс сменился, так и запланированный платёж за билайн не прошёл, и я теперь остался без связи (а, заодно, и без возможности воспользоваться банк-клиентом для ручного проведения платежа)
S>б) планирование платежей в часовом поясе устройства — не очень годная идея. Там будет часовой пояс банка.

Ну а если банк-сервер переедет в другой часовой пояс? (Не физически, понятно, а федеральным законом). Аккурат с той даты, когда платёж.

А если на клиенте я запланировал дорогую операцию не финансового, а технологического характера, и в результате попал на расходы?

А если я настроил запрос на сервис по авторассылке уникальных открыток, и ВСЕ контакты получили по паре разных якобы-от-души поздравлений, показав, что мне на самом деле на них наплевать? (Такой запрос нельзя запланировать на стороннем открыточно-генерирующем сервере, по аналогии с переносом из банк-клиента, т.к. отправка сообщений должна быть с клиентского мессенджера).

В общем, если бы я проектировал такие штуки, я бы подумал о том, чтобы при создании ивента изначально учитывать таймзону и записывать абсолютное время срабатывания, а при смене таймзоны на девайсе перерасчитывать все ивенты. И таким образом гарантировать, что ежемесячно это ежемесячно, а НГ состоится один раз в году, а не 17. Для всех применений, от малозначительных до критических.

Ещё, как вариант, таймзону сделать advanced-параметром при создании ивента, и пусть ответственность будет на юзере. Или совместить этот вариант с предыдущим, сделав по дефолту значение таймзоны "current", но давая выбрать самому.