Лишь бы банить, привыкай уже жить в свободе

Гомофоб ещё пади.

пиздец, ну как так то. В ебаной единственной либе для БД нет работы с таймзонами, в фениксе вообще слова такого нет timezone

нищенский опенсорс мать его

https://github.com/elixir-ecto/ecto/issues/1466

только обсуждают что надо бы это сделать

пиздец, ну как так то. В ебаной единственной либе для БД нет работы с таймзонами, в фениксе вообще слова такого нет timezone

пичаль

Ну это проблема всегда в опен сорс комьюнити, люди делают это в свой фри тайм

никто им за это не платит денег

если конечно не на фул тайме сидеть только пилить опен сорс

я к тому что такого рода болезни и заявление о продакшн реди - несовместимы

скорость, рельсоподобность, смотрите как crud лихо генерится прямо 2007й на дворе

ну ничего, допилят

знаю, просто эрлиадоптером так тяжко быть

для поддержи таймзон нужно поставить timex, чтобы с базой работало еще timex_ecto и ХЕРАК! с Map не работает )

т.е весь апп встанет раком

ах да, еще баги из мира phoenix - ребята когда 1.1 на 1.2 апгрейдили, написали доку о том, что и как поменялось. Вот только они там забыли примерно 99% всего рассказать.

до сих пор выгребаю баги из-за этого

для этого даже генерил “чистый” phoenix app и сравнивал файлы

про доки вообще молчу, обычно в них хрен по деревне или аутдейтед или битые ссылки на свои же доки

“We decided to support timestamptz but not as a default.” - мы решили сделать, а потом положили

нет поддержки timestamptz

и вот ты хранишь utc, думаешь, вот сейчас аппу поставлю таймзону и даты все буду показывать уже с этой таймзоне на клиенте

а хер

phoenix не умеет в таймзоны. Нельзя ему задать дефолт

и тут еще ecto страйкс бэк. Т.к из-за отсутствия таймзон, он отдает datetime в формате - вот тебя дата и время, что UTC - догадаешься

естественно на клиенте нельзя сконвертить такие таймстемпы, приходится их еще нормализировать

типа строки клеить с GMT

если внезапно думаешь, да обойдусь epoch, unixtimestamp вроде бы клиенты все умеют с этим работать. Так тут очередной страйк бэк - Ecto.DateTime умеет кучу всякого мусора типа делать дату от нуля часов, но epoch почил

так, насчет отсутствия нормального формата для фронта, беру слова обратно. есть to_iso8601

уже как-то можно жить )

ладно, пятиминутка ярости окончена

http://pastebin.com/mmLZt4WH

кстати зп для Польшы - очень ок

кстати, всем первопроходцам, которые жаждут лавров аля “я еще рейлс 1 в прод пихал“. Вспомните что проекты на рейлс1 просто выкинули и постарались забыть что такое писали. Рельсы2 или выкинули и с болью протащили дальше, хотя в итоге все же выкидывают.

опыт рейлс1 кстати тоже закопали и пометили, как радиоактивный.

Таймзоны умеет Timex

Я не читал что выше, тороплюсь

умеет, но совсем )

т.е если приедет Ecto.DateTime, то из списка работают только 2 формата

это не говоря о том, что Ecto отдает время без ТЗ, соответственно ISO:Extended выдает херню, а ISO:Extendedz вообще нот имплементед

продираясь сквозь этот пиздец, просто приклейваю .000Z

Таймзоны умеет Timex

для Ecto там все еще в альфа и последний фикс в мастер приехал 2 дня назад. Не работает кстати.

в итоге хак такой: timestamp |> Timex.format!("%FT%T.000Z", :strftime)

это позволяет отдавать ISO8601, который уже на клиенте понимается.

https://github.com/bigardone/phoenix-battleship

https://hexdocs.pm/ecto/Ecto.Repo.html#c:get_by/3 get_by может делать выборку только по одному параметру where ? для 2х параметров надо Query(отдельно запрос писать) ? или get_by умеет 2+ where?

понял,получилось get_by(model, key: value, key: value)

Разобрались с таймзонами?

Вроде ж ок

Утц и таймекс

ERROR: S client not available

Утц и таймекс

если брать datetime из ecto, то таймекс не сможет преобразовать его в валидный таймстемпz

плюс Timex эксплисит форматы не работают. Все валится с not implemented. В доках нет упоминаний ISO:Extendedz, только в сорцах, есессно ничего не работает. Т.к ISO: Extended - это просто 2016-08-20T08:00:00Z где отсутствует хвост

Timex Ecto призван решить проблему, но там все еще не работает

сами фичи сделаны считанные дни назад.

Ecto.datetime.utc - просто дает время в utc, но не делает отметку об этом. Просто мол 21:00 и гадай потом что и как. Все Timex, Calendar ожидают что время будет содержать отметку, мол UTC. Но хрен по всей морде

Timex не умеет делать format в с поддержкой таймзоны, если ее не было в исходном datetime

и вот такой круговорот пиздеца )

Timex предлагают делать так: datetime |> Timex.parse |> Timex.добавить_таймзону(UTC) |> Timex.format

ошибка архитектуры Ecto с полным отсутствием таймзоны как таковой приводит к вот таким костылям.

ну либо ошибка понимания Timex

потому что это логично

Избавиться от того, чтобы задумываться о таймзонах

экто хранит время

ему не обязательно знать что он именно хранит

время и время

число какое-то

Поидее таймекс должен думать о том, что время из ниоткуда может быть в utc

а в чем оно еще собственно может быть

но некая несостыковка чувствуется

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

т.е все решения нацелены на первую часть - оверрайд выдачи datetime из это, чтобы таймстемп содержал упоминание о utc

господа, никто на rabbitmq/kafka не делал аггрегирование данных на лету? оно вообще реально или нет?

мне нужна message queue, но которая будет уметь аггрегировать данные, которые в нее кладут. чтобы я забирал уже аггрегированные данные, а не вынимал по каждой записи и аггрегировал уже потом в памяти сам. и чтобы elixir/erlang смог эти записи аггрегированные вынимать оттуда

kafka вроде умеет такое делать, но похоже там java only опция

Тебе надо прокси или спереди или сзади

Иначе никак