Удалено
Вот именно поэтому не стоит делать покупки через мобильный, маленький экран, всё мелко, какие-то мелочи можно не увидеть. По итогу аэрофлот останется прав, а вы попали на 2500 рублей.
В момент перед самой оплатой билета их мобильное приложение показало правильные даты, которые я выбрал изначально. Это подразумевает, что нажимая кнопку оплатить, именно эти даты я и ожидаю увидеть в билете. Но не увидел, даты поменялись совершенно неожиданно для покупателя, и Аэрофлот тут однозначно не прав.
И 6 дюймов — не такой уж и маленький :)
Да не парьтесь, все размеры хороши =)
чем он оказался прав?

Аэрофлот не прав, поскольку на разных экранах у него разные даты. Когда автор проверял (ну, допустим) подробности заказа, стояла ПРАВИЛЬНАЯ дата. Можно на это давить.
Просто программисты сайта, видимо, знают, что с таймзонами нужно ОЧЕНЬ аккуратно обращаться, а программисты аппликейшена — к сожалению, нет.

Там дело не в экране было а в баге приложения. Хотя насчёт покупок через мобильный я всё равно согласен.

ЗоЗПП с вами не согласится. Покупались билеты на одну дату, а получены на другую. Можно с чистой совестью расторгать договор (без каких-либо комиссий, само собой) и требовать неустойку за каждый день просрочки (плюс стандартный моральный ущерб).
Я же не говорю, что Аэрофлот прав. Естественно они должны всё возместить, т.к. явно ошибка в приложении и покупатель в этом не виноват. Но это Аэрофлот и Россия, здесь у человека нет прав, а только обязанности. Буду очень удивлён, если автору удастся выбить возврат.
С ЗоЗПП вы явно страной ошиблись.
Можете очень удивляться, мне бесплатно поменяли дату
В Аэрофлоте читают Хабр?)

Вряд ли это была реакция на статью, скорее успели обработать претензию.

Ну мне баллы бонусные по претензии тоже возмещали… да, не быстро, и затребовали сканы посадочных, хотя прекрасно же и так в своих системах все данные видят, но в итоге доначислили (а то автоматически только на 1 рейс из 6 начислили мили).
В колл-центре Аэрофлота вообще делают хорошие вещи, однако это не делает их стандартные правила дружественнее, а мобильные приложения и сайты — надёжнее и удобнее.
ЗоЗПП самый человечный закон в России. И не только в России. И один из немногих, которые реально работают.
Плохая идея ругать Россию из-за бугра. Тем более из Вашего бугра.
Какая разница какая страна проживания и какое гражданство при выражении личного мнения?

Современные тенденции дизайна заключаются в том, что на своем большом мониторе при разрешении 1920x1080 на большинстве сайтов видно столько же информации сколько на экране телефона.

Я испытываю некоторый дискомфорт от того, что у моего монитора разрешение 2560х1440, а у телефона — 3880x1440. При этом монитор 27", а телефон меньше 6".
Ну 4к телефон имеет смысл только для VR.
Телефон при этом еще и батарею сильнее жрет из-за большого разрешения…
При этом в «youtube-тесте» у них итоговый аптайм примерно одинаковый от полной батарейки.
4K телефоны как правило можно переключать в обычный фулл-ХД режим
Андрей, а в этом номере бронирования вы все данные ввели фейковые? А то день рождения, email и телефон выглядят уж очень правдоподобными, в отличии от номера паспорта, как и номер участника аэрофлот бонус.
Все реальное я закрыл квадратиками в видео и на скринах, номер паспорта конечно же фейковый. Если я где-то не закрыл — напишите мне в личку.
Сталкивался с подобной ошибкой в сервисе FlixBus. Там в разных интерфейсах сайта время отображалось в разных часовых поясах. Что довольно опасно особенно для времени отправки. В моем случае она смещалась на час назад. А учитывая что я ожидал автобус на промежуточной станции и он задерживался я уж было подумал что он уехал час назад :) Сообщал в поддержку но спустя месяц проблему так и не исправили.
Такое выносить только на публику. Тогда косяки правят чуть ли не на следующий день. Но если косяки связаны с банковскими приложениями(или там где «косяк» вызовет серьезные финансовые/репутационные потери), то стоит подстраховаться и сделать это анонимно.
Этот «косяк» тоже влечет вполне ощутимые репутационные потери.

Чего уж там аэрофлоту терять? :)

Ошибка с датой бронирования была несколько дней на сайте Airbnb — даты в календаре были сдвинуты относительно дней недели на один день! Я бронировал на последние выходные месяца, поэтому можно было не заметить некорректные даты.

На сайте испанских авиалиний Vueling была проблема интерфейса: селектор избранных пассажиров оставался активным после выбора пассажира на рейс, поэтому после скролла страницы вниз к оплате, менялись выбранные пассажиры — а на дальнейших шагах фамилии пассажиров не отображаются, только их кол-во — поэтому даже перепроверить перед оплатой не получилось. Таким образом я купил билеты не на свою жену, а на отца. Претензию компания никак не удовлетворила, поведения селектора не исправили, пришлось платить по-моему 50 евро за смену пассажира.
вообще немного странно: аэрофлот достаточно крупная компания и что бы у них там ничего не валилось дата должна храниться с нулевым смещением и локально приводиться во время запроса. сложно представить как у них там так получилось, если не допускать, конечно, наличия эпических размеров костылей в коде и архитектуре приложения.
Размер и известность компании влияют на качество программных продуктов чуть менее, чем никак. Неправильная дата в билете — это мелочь. Мне вот на днях одна известная страховка прислала полный пакет чужих документов с адресом, телефоном, паспортом и данными на машину. Клиент при регистрации на сайте по ошибке указал неправильный емейл (фамилии похожи). И это отнюдь не первый такой случай.
дело не в том, что компания большая и из-за этого там всё должно быть норм, а в том, что компания имеющая крупную сеть распределённых по миру отделений, просто должна выработать надёжный инструмент для синхронизации времени и даты.
Ну да, а компания, работающая с большим количеством персональных данных, просто обязана выбрать специалистов, способных обеспечить нормальную защиту этих данных. Но это только теоретически, а на практике, увы…
а в той страховой компании, когда регистрируешься, как подтверждается регистрация? Просто в большинстве сайтов это как раз делается при помощи электронной почты. Если страховая, который вы платите деньги и которая очень много о вас знает, регистрирует вас без подтверждения адресов, куда потом может выслать всякие документы-не-для-чужих, то я бы пересмотрел свои с этой компанией взаимоотношения (свалил нафиг). Но при этом, если при оформлении документов, нужно отдельно указывать адрес почты, куда отправлять результаты, тот тут компания не виновата, я бы тоже не стал делать проверку вводимого адреса — это исключительно ответственность клиента.
Вы полностью уверены, что документы отправляются на адрес указанный при регистрации, без подтверждения этого адреса?
Я сам ничего не оформлял, так что не в курсе. Я знаю только, что незнакомый мне человек оформил страховку (судя по всему, на сайте), указал неправильный емейл и на этот адрес без всяких проверок были высланы все документы и одноразовый пароль для входа в кабинет. Я, кстати, потом позвонил этому клиенту (телефон-то в данных был) и объяснил, что с адресом надо быть аккуратнее.

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

PS Если интересно, можете сами попробовать, как подтверждается регистрация в этой компании — это РосГосСтрах, страна должна знать имена своих героев.
ну как… если клиента спросили, куда отправлять, а он и сказал, то как его проверить по вашему: сравнить с адресом из регистрации и спросить, не ошибся ли он, а потом спросить не ошибся ли он подтверждая первый раз… Если бы я был разрабом в этой конторе и мне бы поставили это в вину, я бы отмазался.
ЗЫ Как раз хотел похвалить вас за отсутствие адресной антирекламы, но не успел))
Можно придумать много разных способов. Например, дать клиенту адрес компании и предложить отправить туда запрос на документы. Или предложить зарегистрироваться на сайте и запросить документы из личного кабинета. Или, да, сначала отправить ему письмо с просьбой подтвердить адрес какой-то не слишком личной, но известной только клиенту информацией. Например, номером полиса.

Мне, если честно, трудно представить себе ситуацию, когда все оформляется только на бумаге, а документы нужно отправить на емейл, вписанный от руки. Но даже если такое случилось, адрес подтверждать нужно.

Исключением могут быть случаи, когда адрес используется только для неприватной информации (новости, скидки и т.п.), хотя и это не слишком правильно — подписывать на всякий мусор непричастного человека.

Маленькая компания, большая компания, известная и неизестная. А вот на мой ИНН налоговая перезаписала другого человека. Я даже случайно оплатил его налоги, а уже после заметил. Причем в ЛК были полностью все его паспортные данные, адрес и пр. На компании можно хоть как-то повлиять. А в госучереджении я исправлял последствия их ошибки больше года. Да и до сих пор не все могут исправить.

Заказывал как-то в СБ подробную выписку по счету за год. Через месяц почтой выписка пришла. Но не моя.
Размер влияет на вероятность того, что они с этим багом уже сталкивались. Грубо говоря, приложение лучше протестировано (пользователями), чем малоизвестные.
То, что бага появлялась у пользователей, ещё не гарантирует, что с ней сталкивались разработчики. А то обычно пользователь нарывается на какую-то багу, обращается в компанию, а там его либо вообще игнорируют или бюрократят, либо проблему разгребают в ручном режиме менеджеры или техподдержка, а разрабы о данном инциденте вообще не узнают.
Мы говорим о вероятностях.

Грубый пример: пусть вероятность словить баг 1%, вероятность того, что юзер баг зарепортит — 1%, что пробьётся через бюрократию — 1% (числа с потолка). Итого вероятность прохождения всей цепочки — один на миллион. Если у компании миллионы пользователей — есть шанс, что баг будет исправлен. Если тысячи — практически нет.

Конечно, есть ещё много других вещей, влияющих на вероятность исправления, но «количество запусков» всё же очень значимо.
Ну тут ещё накладываются то, что большой размер компании сильно коррелирует с уровнем забюрократизированности, длинной цепочки, размазыванием ответственности и переусложнённостью процедуры создания фикса.

В маленькой компании менеджер, которому пожаловался клиент, может просто упомянуть о проблеме разработчику, столкнувшись с ним в столовой.
В большой же компании путешествие багрепорта от недовольного клиента до разработчика — это целый квест. И если процессы выстроены не очень хорошо (а так обычно и бывает), то далеко не все баги пройдут этот квест до финальных титров.

В больших компаниях, ориентированных на обслуживание большого потока клиентов, на первой линии поддержки часто сидят люди не разбирающиеся в тонкостях приложения, которых работодатель отнюдь не стимулирует тщательно вникать в каждую отдельную проблему. Их заставляют чётко отрабатывать скрипт общения и не задумываться лишний раз, дабы не тратить драгоценного рабочего времени. Поэтому если скрипт общения с клиентом прописан не очень хорошо, то многие жалобы будут либо блокироваться на этом уровне, либо неправильно маршрутизироваться.
Чаще всего с этим и есть проблемы что даты локально приводятся — многие телефоны тупо не обновляют базу часовых поясов по несколько лет. Правильное поведение — телефон отправляет местоположение а сервер сам вычисляет локальные даты и их присылает на клиент для отображения.

ИМХО правильное решение это две даты со временем:


  1. По Гринвичу.
  2. По выбранной авиакомпанией точке отсчёта.
    И эта информация должна быть видна на всех экранах вплоть до оплаты.
последний раз пытался пользоваться мобильным приложением Аэрофлота 2 года назад. Вижу, что за два года мало что изменилось, все равно без глюков не могут
Статья «Заблуждения программистов относительно времени» будет актуальна всегда. А теперь ещё и с полом надо быть осторожным.
Ага. Больная тема. Недавно бился над кодом на js, который в начале октября час в сутки падал на тестах.
При том, что я JS не знаю, а начало октября- не самое очевидное время для падения- было весело. Оказалось, что прокралась автралийская таймзона- там как раз на зиму переход уже был :D
в начале октября… прокралась автралийская таймзона… на зиму переход
Может, на лето?
Да, спасибо. На лето! Но с точки зрения той баги было без разницы- там просто брался «2 недели назад» с помощью вычитания 14*24*… милисекунд и после перевода часов час в сутки дата оказывалась не та. Билд релиза в этот час не шёл, а нужен он был срочно.

Почитал про часовые пояса в Австралии- это ж вообще трэш и угар. Мало того, что они (что логично) переводят время в противоположную (относительно Европы) сторону, так ещё у них не вся страна часы переводит, есть UTC +9:30 и (а, что вы делаете) UTC +8:45.

Это фигня, в телевещании в NTSC кадры в секундах "високосные". А еще веселуха, когда время перевода стрелок меняют (сидел в CNN правя баги в новом продукте, а мимо чуваки с рациями и матюками в серверную пробегают. Оказалось уже ночь, а в этот год как раз сдвинули правила перехода на летнее время)


Вобщем, после подобных вещей я апплодировал стоя закону об отмене ежегодного насилования часов. Жаль, что не везде по миру

Жаль что этот закон приняли со второй попытки, причем между попытками закончилась поддержка Windows XP

в ХР можно поставить кувейт или багдад
Так же влетал с «Победой», только не с датами а сменой направлений перелета.
С начала думал, что невнимателен, но еще 3-е знакомых влетели так же.
Причем последнего предупреждал, что подозрительно дешевые билеты, поэтому проверялось все тщательно до момента оплаты.
Билеты покупались в разных местах, на сайте «Победы» и в авиасейлс.

Вот так…

В прошлом году летели из Геленджика Победой. Выбираю дату — показывпет цену. Покупаю. Оказалось купил из Краснодара.
Если у Победы нет билетов на это число — то они подставляют ближайший аэропорт. Изза невнимательности пришлось ехать до Краснодара и оттуда уже лететь.

Тут вы из-за бага пострадали, а представьте себе ситуацию: вылет в 2:30, а в 3:00 переводят часы назад на 1 час (дата не меняется). Вылет в первые 2:30 или во вторые?

вылет в 23:30 UTC

Если я правильно помню, в билетах время вылета и прилёта ставится по местному.

Ну как раз пример же привели, когда "по местному" одно и то же время встречается дважды.

Не совсем — билет в посте _может_ быть корректно и однозначно выдан с датами прилёта/вылета по времени аэропортов (время и вылета, и прилёта — однозначное). Я же говорил про ещё худшую проблему — когда дважды встречающееся местное время фигурирует в самом билете. И этого нельзя избежать при текущих правилах выдачи билетов, разве что переделать их, как предложил Drakoninarius.

Интересен реальный механизм решения данной проблемы, вроде логично сделать паузу на вылет в аэропортах, это позволит всем успеть, с другой стороны это решение может сломать график авиакомпаний.

Я думаю, авиакомпании знают заранее и свой график подстраивают...

Решение очевидно: в этот час (на самом деле в два часа) не летать совсем.
(Как у РЖД при переводе в одну сторону поезда тупо час стояли, а в другую — старались догнать расписание за ночь.)

Подозреваю, что так и делается. Криво, но это меньшее из зол.

Я как-то раз разбирался со шкалами времени… Пришёл к выводу, что в компьютере время надо учитывать в шкале TAI или TT, а к ширпотребному времени UTC (да ещё с поясами!) и обратно приводить при помощи подпрограмм конверсии из библиотеки SOFA (Standard of Fundamental Astronomy). Я, правда, немножко покурочил библиотеку, добавив автоматическое вычисление leap seconds из файла с EOP (Earth Orientation Parameters), но это уже мелочи. Это единственный, известный мне, способ корректно работать со временем.
Пару месяцев назад тоже покупал билет у Аэрофлота, решил не качать мобильное приложение и воспользоваться мобильной версией сайта. На поле «Дата Рождения» нельзя выбрать год, его можно только скролить и отсчёт идёт шел с 1900 =)
И под скролить я имею в виду по месяцам…
Писал им, ничего не ответили, пришлось качать приложение для покупки билета :|
А где-нибудь вообще что-нибудь нормально сделано?
Недавно пытался купить билет на сайте «Уральских авиалиний»: сайт упорно считал меня роботом на разных этапах, предлагал капчу и после правильного ввода отсылал на начало.

Купить удалось только зайдя туда с нетбука с Виндоуз: видимо, по их мнению, Линуксом пользуются только роботы и злые хакеры.

(Пару лет назад на сайте другой авиакомпании не было https.)
А Аэрофлот подтвердил что билет действительно был не на ту дату?

Не могло быть так, что дата правильная, а вот косяк просто в отображении а пликухе и в почтовом уведомлении?
Аэрофлот на 5-й день после претензии поменял мне даты билетов, и на 9-ый день прислали письмо, что проблема с мобильным приложением подтвердилась.
Подобная фигня была с KLM. Билеты пришли правильные, а вот на разных экранах были и разные даты и разное время.

Но KLM гибкие ребята, я звонил в Амстердам по скайпу и по телефону решал вопрос.

Таких ляпов немало. Есть и другие варианты усложнения жизни.
А было бы так просто отдельно выводить дату и время в UTC.
Даже простое вроде как указание на местное время для клиента с другой стороны шарика иногда создаёт весёлые квесты.
И в контексте Австралии все ещё веселее становится…

Знаете, вообще это очень обидный косяк со стороны компании. Достаточно представить ситуацию, когда ты в чужой стране и на последние деньги пытаешься попасть домой… Прям фу такими быть.
Ошибки то у всех бывают. Гораздо хуже когда компания отказывается признавать свои ошибки, не смотря на простой алгоритм выявления проблемы(и оперативно её решить). Это уже говорит что с данной фирмой что то не так.
Интересное видео про время и таймзоны. Очевидно, и Вы, и они попали как раз на все эти обычные для времени штуки :)
The Problem with Time & Timezones — Computerphile
youtu.be/-5wpm-gesOY

Дата и время вылета привязываются к UTC или к местному времени в аэропорту вылета? То есть если внезапно изменится часовой пояс, номинальное время вылета (которое пишут в билетах) останется прежним или тоже изменится?

Молодца! Так победим!
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.
Лучшее на Habrahabr

 «Угнать за 60 секунд» на примере одного каршеринга

из песочницы
Valya-rollerсегодня в 11:34
24

Intel устранила найденную экспертами Positive Technologies уязвимость в подсистеме Management Engine

ptsecurityвчера в 18:51
21

Обзор программы Heisenbug 2017 Moscow: сколько нужно тестировщиков, чтобы запустить тесты на атомной электростанции?

olegchirвчера в 17:14
1

Новая многообещающая методология разработки, которую уже назвали «убийцей Agile»*

botyaslonimсегодня в 14:30
6

Выпуск Rust 1.22 (и 1.22.1)

перевод
ozkriffсегодня в 06:19
4

Данные из Google Таблиц на вашем сайте

tutorial
dkomarovskiyсегодня в 11:09
9

Трёхмерная графика с нуля. Часть 2: растеризация

перевод
PatientZeroсегодня в 11:38
2

Развитие стратегий устойчивости

перевод
AloneCoderсегодня в 13:11
0

Черная пятница айтишника, или Сказ о потере данных

JetHabrсегодня в 15:02
3

HPE ProLiant for Microsoft Azure Stack: частичка облака Azure под вашим полным контролем

Tiggerсегодня в 07:40
2