Comments 77
И 6 дюймов — не такой уж и маленький :)
Аэрофлот не прав, поскольку на разных экранах у него разные даты. Когда автор проверял (ну, допустим) подробности заказа, стояла ПРАВИЛЬНАЯ дата. Можно на это давить.
Просто программисты сайта, видимо, знают, что с таймзонами нужно ОЧЕНЬ аккуратно обращаться, а программисты аппликейшена — к сожалению, нет.
Там дело не в экране было а в баге приложения. Хотя насчёт покупок через мобильный я всё равно согласен.
С ЗоЗПП вы явно страной ошиблись.
Вряд ли это была реакция на статью, скорее успели обработать претензию.
Современные тенденции дизайна заключаются в том, что на своем большом мониторе при разрешении 1920x1080 на большинстве сайтов видно столько же информации сколько на экране телефона.
Вы полностью уверены, что документы отправляются на адрес указанный при регистрации, без подтверждения этого адреса?
Правильность адреса надо проверять всегда, если речь идет о закрытой информации. Клиент может ошибиться, но это не повод отправлять его данные кому попало.
PS Если интересно, можете сами попробовать, как подтверждается регистрация в этой компании — это РосГосСтрах, страна должна знать имена своих героев.
ЗЫ Как раз хотел похвалить вас за отсутствие адресной антирекламы, но не успел))
Мне, если честно, трудно представить себе ситуацию, когда все оформляется только на бумаге, а документы нужно отправить на емейл, вписанный от руки. Но даже если такое случилось, адрес подтверждать нужно.
Исключением могут быть случаи, когда адрес используется только для неприватной информации (новости, скидки и т.п.), хотя и это не слишком правильно — подписывать на всякий мусор непричастного человека.
Маленькая компания, большая компания, известная и неизестная. А вот на мой ИНН налоговая перезаписала другого человека. Я даже случайно оплатил его налоги, а уже после заметил. Причем в ЛК были полностью все его паспортные данные, адрес и пр. На компании можно хоть как-то повлиять. А в госучереджении я исправлял последствия их ошибки больше года. Да и до сих пор не все могут исправить.
Грубый пример: пусть вероятность словить баг 1%, вероятность того, что юзер баг зарепортит — 1%, что пробьётся через бюрократию — 1% (числа с потолка). Итого вероятность прохождения всей цепочки — один на миллион. Если у компании миллионы пользователей — есть шанс, что баг будет исправлен. Если тысячи — практически нет.
Конечно, есть ещё много других вещей, влияющих на вероятность исправления, но «количество запусков» всё же очень значимо.
В маленькой компании менеджер, которому пожаловался клиент, может просто упомянуть о проблеме разработчику, столкнувшись с ним в столовой.
В большой же компании путешествие багрепорта от недовольного клиента до разработчика — это целый квест. И если процессы выстроены не очень хорошо (а так обычно и бывает), то далеко не все баги пройдут этот квест до финальных титров.
В больших компаниях, ориентированных на обслуживание большого потока клиентов, на первой линии поддержки часто сидят люди не разбирающиеся в тонкостях приложения, которых работодатель отнюдь не стимулирует тщательно вникать в каждую отдельную проблему. Их заставляют чётко отрабатывать скрипт общения и не задумываться лишний раз, дабы не тратить драгоценного рабочего времени. Поэтому если скрипт общения с клиентом прописан не очень хорошо, то многие жалобы будут либо блокироваться на этом уровне, либо неправильно маршрутизироваться.
При том, что я JS не знаю, а начало октября- не самое очевидное время для падения- было весело. Оказалось, что прокралась автралийская таймзона- там как раз на зиму переход уже был :D
Почитал про часовые пояса в Австралии- это ж вообще трэш и угар. Мало того, что они (что логично) переводят время в противоположную (относительно Европы) сторону, так ещё у них не вся страна часы переводит, есть UTC +9:30 и (а, что вы делаете) UTC +8:45.
Это фигня, в телевещании в NTSC кадры в секундах "високосные". А еще веселуха, когда время перевода стрелок меняют (сидел в CNN правя баги в новом продукте, а мимо чуваки с рациями и матюками в серверную пробегают. Оказалось уже ночь, а в этот год как раз сдвинули правила перехода на летнее время)
Вобщем, после подобных вещей я апплодировал стоя закону об отмене ежегодного насилования часов. Жаль, что не везде по миру
С начала думал, что невнимателен, но еще 3-е знакомых влетели так же.
Причем последнего предупреждал, что подозрительно дешевые билеты, поэтому проверялось все тщательно до момента оплаты.
Билеты покупались в разных местах, на сайте «Победы» и в авиасейлс.
Вот так…
Тут вы из-за бага пострадали, а представьте себе ситуацию: вылет в 2:30, а в 3:00 переводят часы назад на 1 час (дата не меняется). Вылет в первые 2:30 или во вторые?
Если я правильно помню, в билетах время вылета и прилёта ставится по местному.
Ну как раз пример же привели, когда "по местному" одно и то же время встречается дважды.
(Как у РЖД при переводе в одну сторону поезда тупо час стояли, а в другую — старались догнать расписание за ночь.)
Недавно пытался купить билет на сайте «Уральских авиалиний»: сайт упорно считал меня роботом на разных этапах, предлагал капчу и после правильного ввода отсылал на начало.
Купить удалось только зайдя туда с нетбука с Виндоуз: видимо, по их мнению, Линуксом пользуются только роботы и злые хакеры.
(Пару лет назад на сайте другой авиакомпании не было https.)
Не могло быть так, что дата правильная, а вот косяк просто в отображении а пликухе и в почтовом уведомлении?
The Problem with Time & Timezones — Computerphile
youtu.be/-5wpm-gesOY
Дата и время вылета привязываются к UTC или к местному времени в аэропорту вылета? То есть если внезапно изменится часовой пояс, номинальное время вылета (которое пишут в билетах) останется прежним или тоже изменится?
Как не надо работать с часовыми поясами или Аэрофлот-фэйл