IK
На патреоне будет со временем
Size: a a a
2020 October 02
DB
Не могу сдержать эмоций!!! Прям жду с нетерпением!!!
IK
Пока даже не обещаю что в этом году
IK
Это сложная работа и за идею
DB
Жаль только что ReScript не проникнет в мир js так как это сделал тайпскрипт.
IK
И не надо
DZ
Какой шанс, что с ReScript не случится такая же история как с CoffeeScript?
EN
Скажу намеком - если бы не было боли мы бы с вами тут не общались 🙂
Ну я вижу боль в следующем:
1) Если время пришло как 2020-09-17T08:44:03.543+0300, то применяя свой timeZone, js исключает тот, который пришел с данными, то есть 08:44:03.543+0300 становится 05:44:03.543 и уже сюда применяет timeZone клиента. Например, у клиента UTC+1, то получается 06:44:03.543 (что неправильно)
2) Если время пришло как 2020-09-17T08:44:03.543Z, то применяя timeZone клиента, js применяет его напрямую и получается - 09:44:03.543
Вы именно это имели в виду или кейсы похуже ?)
И да, дата, приходящая с бэка уже с сформированным UTC (2020-09-17T08:44:03.543Z) cчитается неким де-факто (при передачах с бэка на фронт) или не всегда это удобно ?
1) Если время пришло как 2020-09-17T08:44:03.543+0300, то применяя свой timeZone, js исключает тот, который пришел с данными, то есть 08:44:03.543+0300 становится 05:44:03.543 и уже сюда применяет timeZone клиента. Например, у клиента UTC+1, то получается 06:44:03.543 (что неправильно)
2) Если время пришло как 2020-09-17T08:44:03.543Z, то применяя timeZone клиента, js применяет его напрямую и получается - 09:44:03.543
Вы именно это имели в виду или кейсы похуже ?)
И да, дата, приходящая с бэка уже с сформированным UTC (2020-09-17T08:44:03.543Z) cчитается неким де-факто (при передачах с бэка на фронт) или не всегда это удобно ?
M
El Nasurov
Ну я вижу боль в следующем:
1) Если время пришло как 2020-09-17T08:44:03.543+0300, то применяя свой timeZone, js исключает тот, который пришел с данными, то есть 08:44:03.543+0300 становится 05:44:03.543 и уже сюда применяет timeZone клиента. Например, у клиента UTC+1, то получается 06:44:03.543 (что неправильно)
2) Если время пришло как 2020-09-17T08:44:03.543Z, то применяя timeZone клиента, js применяет его напрямую и получается - 09:44:03.543
Вы именно это имели в виду или кейсы похуже ?)
И да, дата, приходящая с бэка уже с сформированным UTC (2020-09-17T08:44:03.543Z) cчитается неким де-факто (при передачах с бэка на фронт) или не всегда это удобно ?
1) Если время пришло как 2020-09-17T08:44:03.543+0300, то применяя свой timeZone, js исключает тот, который пришел с данными, то есть 08:44:03.543+0300 становится 05:44:03.543 и уже сюда применяет timeZone клиента. Например, у клиента UTC+1, то получается 06:44:03.543 (что неправильно)
2) Если время пришло как 2020-09-17T08:44:03.543Z, то применяя timeZone клиента, js применяет его напрямую и получается - 09:44:03.543
Вы именно это имели в виду или кейсы похуже ?)
И да, дата, приходящая с бэка уже с сформированным UTC (2020-09-17T08:44:03.543Z) cчитается неким де-факто (при передачах с бэка на фронт) или не всегда это удобно ?
Не парься и всегда отдавай юникс
v
Misha
Не парься и всегда отдавай юникс
Таймстамп?
M
Таймстамп?
Да
M
А на фронте уже как хочешь
v
Зачем же вы так)
Пусть сделает по нормальному)
Пусть сделает по нормальному)
EN
Misha
Не парься и всегда отдавай юникс
Я не отдаю, моя участь принимать время на фронте и обрабатывать ее))
M
Зачем же вы так)
Пусть сделает по нормальному)
Пусть сделает по нормальному)
Если честно, то не вижу в этом проблемы
NR
Конструктор Date нормально принимает ISO. Не понял проблемы
v
Конструктор Date нормально принимает ISO. Не понял проблемы
А таймзону?
Коллеге нужно чтобы время оставалось как есть не мотор на ьаймзону
Коллеге нужно чтобы время оставалось как есть не мотор на ьаймзону
v
Misha
Если честно, то не вижу в этом проблемы
От текущих описанных и заканчивая тем что БД с типом данных дата работать удобнее.
v
Misha
Если честно, то не вижу в этом проблемы
IK
Какой шанс, что с ReScript не случится такая же история как с CoffeeScript?
Рескрипт просто другой АСТ для ocaml