Нужно ли мне узнать фактический часовой пояс клиента или я могу предположить, что они все находятся в часовом поясе EST?(Веб-приложение только для США) - PullRequest
1 голос
/ 04 сентября 2011

У меня есть вопрос по поводу даты и времени в моем веб-приложении. Приложение будет продавать ежемесячные подписки. Показывает даты только когда клиенты покупают и отменяют подписки. Клиенты могут приобрести дополнительные услуги в середине месяца. Приложение рассчитывает пропорциональную плату для клиента до его юбилейной даты.

Я буду хранить даты / время в UTC. Это только для клиентов из США.

Я рассматриваю следующие варианты и хотел бы получить отзывы от более опытных разработчиков:

1 - всегда указывать даты в EST. Я могу добавить небольшую подпись, объясняющую, что во всех подписках используется EST. Это было бы просто, поскольку мне не пришлось бы иметь дело с часовыми поясами клиентов. Однако я не уверен, что клиенты будут откладывать это. Есть мысли?

2 - всегда указывать даты в EDT. Это, вероятно, будет работать не очень хорошо, поскольку будет сложнее объяснить причину его использования. Однако я считаю, что это будет проще обрабатывать, чем EST.

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

4 - запросить местоположение клиента (город и штат) и рассчитать часовой пояс самостоятельно.

5 - попытайтесь угадать часовой пояс клиента на основе его IP или другого метода (идеи ???).

Опции 3, 4 и 5, вероятно, будут наиболее удобными для пользователя. Вариант 1 представляется наиболее простым для реализации.

Извините за длинный пост. Если бы вы нашли время, чтобы прочитать его, не могли бы вы уделить немного больше времени и поделиться своими мыслями и опытом?

Спасибо.

ОБНОВЛЕНИЕ 1 - 3/3/2011 - 17:08 MST

Только что обнаружил, что PayPal записывает транзакции с использованием PDT и показывает их клиенту, используя локальный часовой пояс клиента, который они установили при регистрации в PayPal.

Теперь я склонен:

1 - показывать текущую дату, используя PDT (для выравнивания с PayPal) - я, вероятно, изменю код для отображения даты и времени PDT. В настоящее время я показываю только дату. Я верю, что клиенту будет понятнее, если я покажу время.

2 - я не буду показывать дату юбилея. Я позволю PayPal справиться с этим. Я просто скажу, что это ежемесячный счет.

3 - Когда клиенты добавляют новую услугу, я рассчитываю пропорциональные значения с использованием PDT и предоставлю им трехдневный льготный период для учета различий в часовых поясах (спасибо Роберту Леви ниже за предложение) и обработку PayPal (I не хочу взимать с них пропорциональную сумму, если они составляют всего пару дней от своих регулярных ежемесячных платежей).

Есть мысли?

Обновление 2 - 03.09.2011 - 21:01 MST

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

Звучит как план. Что ты думаешь?

1 Ответ

2 голосов
/ 04 сентября 2011

Просто добавьте льготный период в 24 часа от UTC.Легко кодировать, без лишнего пользовательского интерфейса и вряд ли расстроит любого клиента.

...