Спасибо, что дополнили информацию. Тем не менее есть разница между возможностью использования (фактически - запуска) и использования в высоком качестве (скорости).
Мне удалось запустить нейросеть для генерации автодополнения кода на ryzen 5 без видеокарты при адекватном использовании. В статье не учтены некоторые нюансы (например: для видеокарт Nvidia нейросетки адаптированы лучше и т.п.) намеренно, чтобы не грузить читателя.
Относительно хранения "Europe/Moscow". Та же библиотека MomentJS (самая популярная библиотека для работы со временем в JS/TS) имеет подбиблиотеку по работе с TZ. В ней есть работа с данными в формате "Europe/Moscow". В ответ функция вернет TZ. Хороший вариант для хранения.
На практике данный подход не применял, но если есть условный словарь для расшифровки (поддерживаемый кем-то), то будет хорошим вариантом для работы со временем.
В этом случае думаю, что хранение "Время в этой временной зоне" будет излишним.
-------------------
Не продумывал смещение времени относительно текущей геопозиции пользователя, но не думаю, что это является реальным кейсом. Я бы сказал, что тут нюанс правильной интеграции системы бэка и фронта. Считаю что много тут зависит от ТЗ.
Кейс 1. Допустим у нас есть необходимость создания типичного отображения времени подачи заявки на бэк. Чтобы не добавлять геополитическую логику в данную систему, я бы оставил это на стороне фронта:
Фронт получает ISO-string UTC (00:00) и смещение времени по сохранены данным
Пользователю отображается время подачи заявки И временной пояс подачи заявки
Да, могут быть заявки в техподдержку из-за непонимания юзверя, но тут можно дополнять оповещение времени тултипом и др элементами UI/UX. Так что задача уже не программиста как таковая, а дизайнера.
Кейс 2 - отображение времени отправления поезда. Тут следует отменить, что существует шкала времени железной дороги в каждой стране и она отмечается по одному городу (смещение времени считается от него), но пока забудем об этом.
В этом кейсе также фронт сам разруливает что отображать:
Фронт получает ISO-string UTC и смещение времени относительно пункта отправления/прибытия
Фронт отображает время, совмещая ISO-string с полученным смещением
Фронт отображает сноску "время местное"
Тут есть нюанс, что отправление и прибытие могут быть в разных часовых поясах и датах. Если есть желание не раздувать логику на бэке и обработать данные на фронте, то данные однозначно должны быть с указанием времени TZ местного времени для просчета (будет это ISO-string+TZ или ISO-string и смещение отдельными параметрами - не важно).
Кейс 3 - сервис аналитики. Допустим нам нужно получать данные, обрабатывать их и выдавать статистику. Тут стоит отметить, что стоит уделить отдельное время на компановку задачи. В обычном понимании оператора, скорее всего, нужно будет отображать реальное время пользователя у пользователя. Тут нам и поможет смещение времени, переданное от него.
Клиент что-то творит, предаются данные в формате ISO-string с TZ.
Бэк разделяет данные на UTC и смещение
Фронт аналитики получает ISO-string и смещение времени
Фронт аналитики совмещает данные и выводит, например, график, с реальным временем пользователя
Возможно для данного кейса это и будет решением, но звучит довольно дико.
Вместо того чтобы терять данные, я бы создал дополнительное поле. Можно добавить отдельную таблицу для отметки времени и сделать связь 1 к 1. Излишним это будет только на первый взгляд.
Игнорировать TZ может быть очень опасно в будущем, если, кончено, приложение будет реально использоваться в коммерции.
Могу предложложить сделать так:
у юзера в настройках задается тайм зона, изначально берущаяся из часов
в приложении будет очевидная единая тайм зона, которую можно менять при желании
можно переопределять TZ автоматически при заходе юзера в приложения (добавить пункт "автоматически" в настройки юзверя)
эта тайм зона будет использоваться для вставки в angular pipe вторым аргументом
скорее как бонус
на сервер будет отправляться время с TZ, но в базе сохраняться время UTC
соблюдаем единую шкалу измерений
при необходимости, можно сохранить изначальную TZ в качестве сдвига в соседнем столбце
сдвиг будет легко вычислить
при обмене данными FE-BE использовать iso-string, при получении на BE можно (при необходимости, например, для расчетов) использовать перевод в timestamp UTC
это позволит применять расчеты в фильтре запроса к БД; все данные в единой шкале изменений и не будет проблем в вычислениях
Итого:
Вычисления доступны, все данные в одной системе исчеслений
Структура простая и очевидная
Структура удобна для фронта и бэка, формат унифицирован
Timestamp = time in ms (UTC) from 1970/1/1 (link). Timestamp имеет формат целых чисел, iso-string имеет формат строки. В iso-string можно передать TZ, в timestamp - нет.
Предполагаю, что разговор о логировании действий пользователя системой. Если говорить о таблице в БД, можно предположить:
В условной функции запроса по энпоинту можно совмещать в обе стороны iso-string+TZ. В любом языке данный функционал имеет место быть.
Если речь об запросах в БД, то возможно было бы удобно создать дополнительное поле user_time в формате timestamp. Это позволит свести расчеты запросов в единую плоскость для конкретных кейсов, но выдавать другой системе для отображения и использования придется всю строку (иначе бытовые расчеты будут невозможны). Приходилось иметь дело с api, в которой очень много неясных систем отсчета, оттуда и родилась статья по унификации.
Спасибо, что дополнили информацию. Тем не менее есть разница между возможностью использования (фактически - запуска) и использования в высоком качестве (скорости).
Мне удалось запустить нейросеть для генерации автодополнения кода на ryzen 5 без видеокарты при адекватном использовании. В статье не учтены некоторые нюансы (например: для видеокарт Nvidia нейросетки адаптированы лучше и т.п.) намеренно, чтобы не грузить читателя.
Да, спасибо. Добавил. Потёрлось при редактировании.
На 7b нужно что то типа гига на видеокарте. Можно запустить чисто на процессоре. Про 32b и больше есть сноска.
Это больше черта Реакта, а не Ангуляра. Как раз таки это в целом не angular way.
Проверил, не сработало. Может не с тем варю.
Ценная информация, спасибо
Относительно хранения "Europe/Moscow". Та же библиотека MomentJS (самая популярная библиотека для работы со временем в JS/TS) имеет подбиблиотеку по работе с TZ. В ней есть работа с данными в формате "Europe/Moscow". В ответ функция вернет TZ. Хороший вариант для хранения.
На практике данный подход не применял, но если есть условный словарь для расшифровки (поддерживаемый кем-то), то будет хорошим вариантом для работы со временем.
В этом случае думаю, что хранение "Время в этой временной зоне" будет излишним.
-------------------
Не продумывал смещение времени относительно текущей геопозиции пользователя, но не думаю, что это является реальным кейсом. Я бы сказал, что тут нюанс правильной интеграции системы бэка и фронта. Считаю что много тут зависит от ТЗ.
Кейс 1. Допустим у нас есть необходимость создания типичного отображения времени подачи заявки на бэк. Чтобы не добавлять геополитическую логику в данную систему, я бы оставил это на стороне фронта:
Фронт получает ISO-string UTC (00:00) и смещение времени по сохранены данным
Пользователю отображается время подачи заявки И временной пояс подачи заявки
Да, могут быть заявки в техподдержку из-за непонимания юзверя, но тут можно дополнять оповещение времени тултипом и др элементами UI/UX. Так что задача уже не программиста как таковая, а дизайнера.
Кейс 2 - отображение времени отправления поезда. Тут следует отменить, что существует шкала времени железной дороги в каждой стране и она отмечается по одному городу (смещение времени считается от него), но пока забудем об этом.
В этом кейсе также фронт сам разруливает что отображать:
Фронт получает ISO-string UTC и смещение времени относительно пункта отправления/прибытия
Фронт отображает время, совмещая ISO-string с полученным смещением
Фронт отображает сноску "время местное"
Тут есть нюанс, что отправление и прибытие могут быть в разных часовых поясах и датах. Если есть желание не раздувать логику на бэке и обработать данные на фронте, то данные однозначно должны быть с указанием времени TZ местного времени для просчета (будет это ISO-string+TZ или ISO-string и смещение отдельными параметрами - не важно).
Кейс 3 - сервис аналитики. Допустим нам нужно получать данные, обрабатывать их и выдавать статистику. Тут стоит отметить, что стоит уделить отдельное время на компановку задачи. В обычном понимании оператора, скорее всего, нужно будет отображать реальное время пользователя у пользователя. Тут нам и поможет смещение времени, переданное от него.
Клиент что-то творит, предаются данные в формате ISO-string с TZ.
Бэк разделяет данные на UTC и смещение
Фронт аналитики получает ISO-string и смещение времени
Фронт аналитики совмещает данные и выводит, например, график, с реальным временем пользователя
Сноски тут не понадобятся
Возможно для данного кейса это и будет решением, но звучит довольно дико.
Вместо того чтобы терять данные, я бы создал дополнительное поле. Можно добавить отдельную таблицу для отметки времени и сделать связь 1 к 1. Излишним это будет только на первый взгляд.
Игнорировать TZ может быть очень опасно в будущем, если, кончено, приложение будет реально использоваться в коммерции.
Могу предложложить сделать так:
у юзера в настройках задается тайм зона, изначально берущаяся из часов
в приложении будет очевидная единая тайм зона, которую можно менять при желании
можно переопределять TZ автоматически при заходе юзера в приложения (добавить пункт "автоматически" в настройки юзверя)
эта тайм зона будет использоваться для вставки в angular pipe вторым аргументом
скорее как бонус
на сервер будет отправляться время с TZ, но в базе сохраняться время UTC
соблюдаем единую шкалу измерений
при необходимости, можно сохранить изначальную TZ в качестве сдвига в соседнем столбце
сдвиг будет легко вычислить
при обмене данными FE-BE использовать iso-string, при получении на BE можно (при необходимости, например, для расчетов) использовать перевод в timestamp UTC
это позволит применять расчеты в фильтре запроса к БД; все данные в единой шкале изменений и не будет проблем в вычислениях
Итого:
Вычисления доступны, все данные в одной системе исчеслений
Структура простая и очевидная
Структура удобна для фронта и бэка, формат унифицирован
Пробовал вторым аргументом передавать в пайп таймзону?
Предварительно напишу:
Timestamp = time in ms (UTC) from 1970/1/1 (link). Timestamp имеет формат целых чисел, iso-string имеет формат строки. В iso-string можно передать TZ, в timestamp - нет.
Предполагаю, что разговор о логировании действий пользователя системой. Если говорить о таблице в БД, можно предположить:
В условной функции запроса по энпоинту можно совмещать в обе стороны iso-string+TZ. В любом языке данный функционал имеет место быть.
Если речь об запросах в БД, то возможно было бы удобно создать дополнительное поле
user_timeв формате timestamp. Это позволит свести расчеты запросов в единую плоскость для конкретных кейсов, но выдавать другой системе для отображения и использования придется всю строку (иначе бытовые расчеты будут невозможны). Приходилось иметь дело с api, в которой очень много неясных систем отсчета, оттуда и родилась статья по унификации.