Ф>Это даже не вопрос, а скорее побомбить: меня эта тема с DateTime.Now в своё время очень долго вымораживала. Ф>Вот неужели нельзя было заранее подумать, что люди будут тесты писать??????!!!!!1111 Ф>Идиоты!!!!!
Этот вопрос не так давно обсуждался где-то в СВ.
Вкратце: идиоты не авторы FCL, а те, кто использует DateTime.Now в коде, который собираются тестировать.
Если у вас в бизнес-логике есть функция, поведение которой зависит от времени, то она должна быть детерминистической и время в неё должно передаваться параметром.
То есть не GetReportOnCurrentBalances(), а GetReportOnCurrentBalances(DateTime balanceDate).
По-хорошему эта функция и в данные сама лазить не должна; генерация отчёта должна принимать исходные данные и отдавать отчёт.
Тогда вы сможете все сложные вещи покрыть дешёвыми юнит-тестами.
А корректность клеевого кода, который как раз и делает вызов SendEmailWithAttachment(configuration.AdminEmail, $"Balances on {DateTime.Now}", GeneratePDFReport(GetBalancesData(DateTime.Now))), проверяется интеграционными тестами. Тут уже шанс словить ошибку мал (т.к. непротестированного кода очень мало), поэтому длинный цикл тестирования приемлем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Философ, Вы писали: Ф>В смысле!? Ты хочешь сказать, что если бы TimeProvider был интерфейсом, то ты бы мог свой треугольник сделать TimeProvider'ом — сделать реализацию это интерфейса? Типа так не получается — ты об этом? Ф>Треугольник — это я конечно совсем загнул, но например стрим, или сервис.... Ты об этом, вот так?
Конечно. Я мог бы сделать свою реализацию ITimeProvider более-менее где угодно, в том числе и в классе, который реализует пачку провайдеров разных сервисов согласованным образом.
После введения default interface members польза от абстрактных классов в API упала до примерно нуля.
Это если вообще опираться на предположение, что методы тайм-провайдера сильно связаны между собой. В противном случае имело бы смысл отказаться и от интерфейса в пользу отдельных функций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Это даже не вопрос, а скорее побомбить: меня эта тема с DateTime.Now в своё время очень долго вымораживала.
Вот неужели нельзя было заранее подумать, что люди будут тесты писать??????!!!!!1111
Идиоты!!!!!
UPD: я понимаю, что те прикладные программисты, которые написали DateTime.Now должны были сами подумать о "ближних", но уже написали...
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>Это даже не вопрос, а скорее побомбить: меня эта тема с DateTime.Now в своё время очень долго вымораживала. Ф>Вот неужели нельзя было заранее подумать, что люди будут тесты писать??????!!!!!1111 Ф>Идиоты!!!!!
Идиоты запрещают в отладочной виртуалке поменять дату?
Здравствуйте, Ночной Смотрящий, Вы писали:
Q>>И принимают его в некоторых своих API вроде CancellationTokenSource или PeriodicTimer. НС>Абстрактный класс как основа API в 2023 году?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Qbit86, Вы писали:
Q>>Microsoft добавили абстракцию TimeProvider в каком-то превью .NET 8: https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/TimeProvider.cs Q>>И принимают его в некоторых своих API вроде CancellationTokenSource или PeriodicTimer.
НС>Абстрактный класс как основа API в 2023 году?
Здравствуйте, Ночной Смотрящий, Вы писали:
Q>>Microsoft добавили абстракцию TimeProvider в каком-то превью .NET 8: https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/TimeProvider.cs Q>>И принимают его в некоторых своих API вроде CancellationTokenSource или PeriodicTimer. НС>Абстрактный класс как основа API в 2023 году?
Хуже, что они в один класс упихали часы, перформанс тайм-стампы, да ещё и таймер. При этом нет вменяемой возможности сделать часы в заданной таймзоне.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Ф>>>А вот сделать часы в заданной таймзоне есть: Ф>>>Вот этот метод Ф>>> Ф>>> public virtual TimeZoneInfo LocalTimeZone { get => TimeZoneInfo.Local; } Ф>>>
Ф>>>плюс вот этот Ф>>> Ф>>> public DateTimeOffset GetLocalNow() Ф>>> { Ф>>> DateTimeOffset utcDateTime = GetUtcNow(); Ф>>> TimeZoneInfo zoneInfo = LocalTimeZone; Ф>>>
Ф>>>дают нам часы в любой таймзоне. Y>>В каком смысле в любой? Y>>https://learn.microsoft.com/en-us/dotnet/api/system.timezoneinfo.local?view=net-7.0 Y>>
Y>>The local time zone is the time zone on the computer where the code is executing.
Y>>Это не любая.
Ф>Блин, что за хрень!? Разговор про виртуальные методы одного класса (!абстрактного), а ты копипастишь описание СТАТИЧЕСКОГО свойства другого класса. WTF!? Ф>Ну это же не политика, блин, это другой раздел — меру то нужно знать!
Что-то ты сильно разволновался с утра, молюсь за твоё здоровье. Ты ж первый начал копипастить реализации.
Здравствуйте, Sinclair, Вы писали:
S>Конечно. Я мог бы сделать свою реализацию ITimeProvider более-менее где угодно, в том числе и в классе, который реализует пачку провайдеров разных сервисов согласованным образом.
Это нарушение SRP
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>·>Так это надо наследника писать и переопределять метод. Ф>И в чём проблема? А как ты хотел?
Через setter, wither или конструктор.
Представь себе у тебя есть инстанс timeProvider и тебе нужно получить такой же, но в другой таймзоне. Придётся писать наследника-делегата с переопределением одного метода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Абстрактный класс как основа API в 2023 году?
Это ради невиртуального:
public TimeSpan GetElapsedTime (long startingTimestamp);
Собсно, это целевой метод, вокруг которого всё работает, он должен быть максимально легковесным, т.к. может вызываться в бесконечном цикле какого-нить диспетчера.
Здравствуйте, vdimas, Вы писали:
V>Можно переопределить на более легковесный Environment.TickCount
Он не более легковесный — точно такой же. Это разные счётчки: твой считает кол-во миллисекунд о старта системы, а то что ты хочешь заменить считает тики вроде-бы со 100 ns точностью.
Всё сказанное выше — личное мнение, если не указано обратное.
The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached.
Здравствуйте, Философ, Вы писали:
Ф>Это даже не вопрос, а скорее побомбить: меня эта тема с DateTime.Now в своё время очень долго вымораживала. Ф>Вот неужели нельзя было заранее подумать, что люди будут тесты писать??????!!!!!1111 Ф>Идиоты!!!!!
Тут есть одна проблема. DateTime.Now не единственный источник времени в системе. У нас, например, в продукте кроме дотнетного гуя еще серверная плюсовая часть есть. Так что если бы можно было подменить DateTime.Now — это нас не спасло бы. В тестах используется классец который переводит время и возвращает его обратно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ф>Когда я работал над тем проектом, там поддерживалась Win2k3. Поэтому .net 4.
Понятно. Уже как-то забываешь, что люди с FW до сих пор работают.
А с Core — ISystemClock. Хотя тоже необязательно. Я ещё просто делаю IDateTimeService, а в нём все нужные методы для работы с датой/временем. И DateTime.Now или UtcNow никогда в проекте напрямую не использую. Таким образом и в юнит-тестах всё с лёгкостью мокается.
А внутри реализации IDateTimeService можно или ISystemClock использовать, или DateTime.UtcNow напрямую. Поскольку инкапсулировано, это уже неважно.
И кстати местный часовой пояс лучше не из компьютера брать, а явно в конфигурации прописывать, а в DateTimeService уже все нужные преобразования реализовать. За основу всегда брать UTC.
Это для веб-сайтов. Для десктопа наверно лучше часовой пояс из компьютера.
Я думал ещё внедрить Noda Time
Здравствуйте, ·, Вы писали:
·>Хуже, что они в один класс упихали часы, перформанс тайм-стампы, да ещё и таймер. При этом нет вменяемой возможности сделать часы в заданной таймзоне.
Там вот это ппц — ппц.
public virtual long GetTimestamp() => Stopwatch.GetTimestamp();
Просто чудовищные грабли.
А вот сделать часы в заданной таймзоне есть:
Вот этот метод
public virtual TimeZoneInfo LocalTimeZone { get => TimeZoneInfo.Local; }
Здравствуйте, Sharov, Вы писали: S>Ну а как до этого с этими ограничениями жили?
Плохо жили.
А в тех местах, где этих ограничений не вводили, жили хорошо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ф>·>Хуже, что они в один класс упихали часы, перформанс тайм-стампы, да ещё и таймер. При этом нет вменяемой возможности сделать часы в заданной таймзоне.
Ф>А вот сделать часы в заданной таймзоне есть: Ф>Вот этот метод Ф>
Ф> public virtual TimeZoneInfo LocalTimeZone { get => TimeZoneInfo.Local; }
Ф>
Y>The local time zone is the time zone on the computer where the code is executing.
Y>Это не любая.
Блин, что за хрень!? Разговор про виртуальные методы одного класса (!абстрактного), а ты копипастишь описание СТАТИЧЕСКОГО свойства другого класса. WTF!?
Ну это же не политика, блин, это другой раздел — меру то нужно знать!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>В чем проблема? S>В ограничениях на иерархию наследования.
В смысле!? Ты хочешь сказать, что если бы TimeProvider был интерфейсом, то ты бы мог свой треугольник сделать TimeProvider'ом — сделать реализацию это интерфейса? Типа так не получается — ты об этом?
Треугольник — это я конечно совсем загнул, но например стрим, или сервис.... Ты об этом, вот так?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, ·, Вы писали:
Ф>>·>Так это надо наследника писать и переопределять метод. Ф>>И в чём проблема? А как ты хотел? ·>Через setter, wither или конструктор. ·>Представь себе у тебя есть инстанс timeProvider и тебе нужно получить такой же, но в другой таймзоне. Придётся писать наследника-делегата с переопределением одного метода.
А с учётом этого, когда они добавят очередной виртуальнй метод в своё поделие, твой делегат по тихому сломается, будет делегировать всё, кроме этого нового метода.
Ну не умеют в микрософте вменяемый api делать, лучше бы тупо с явы передирали, и то бы лучше получалось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>GetTickCount64 — это просто чтение кешированной переменной, значение которой обновляется каждый раз при срабатывании системного таймера.
В случае Stopwatch.GetTimestamp() даже записи в переменную может не быть.
V>В общем, первый способ имеет низкую разрешающую способность, но дешевый. V>Второй способ имеет лучшую разрешающую способность, но дорогой. ))
В абсолютном большинстве случаев он столь же дешёвый, если не дешевле: за кадром выполняется команда RDTSC, которая копирует содержимое MSR в EDX:EAX — обращение к памяти не происходит. А MSR обновляется сам, всегда.
Такое поведение в абсолютном большинстве случаев. Иное — если недоступна RDTSC, то такого на практике под виндой ни у кого пока не было (ни у кого из миллиардов пользователей). Иное поведение может быть, если винда принудительно настроена на использование HPET.
Если недоступны HPET и RDTS, то будет использован тот же таймер что ты предлагаешь, с соответствующей точностью.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
V>>GetTickCount64 — это просто чтение кешированной переменной, значение которой обновляется каждый раз при срабатывании системного таймера. Ф>В случае Stopwatch.GetTimestamp() даже записи в переменную может не быть.
Это всё-равно в разы дороже.
Просто замерь и убедись.
V>>Второй способ имеет лучшую разрешающую способность, но дорогой. )) Ф>В абсолютном большинстве случаев он столь же дешёвый, если не дешевле: за кадром выполняется команда RDTSC, которая копирует содержимое MSR в EDX:EAX — обращение к памяти не происходит.
Ой, блин, из глаз кровь читать эту чушь.
Это вызов ф-ии АПИ QueryPerformanceCounter, которая вызывает драйвер через KeQueryPerformanceCounter, а драйвер зависит от проца/чипсета, бо входу еще процы, где RDTSC возвращала разные значения для каждого ядра и это длилось почти десятилетие, такой беспредел. Плюс требуется запрашивать QueryPerformanceFrequency, а она у процов тоже гуляла постоянно.
Чтобы избежать ошибок и проблем с переносимостью, настоятельно рекомендуется использовать QPC вместо регистра TSC или инструкций процессора RDTSC или RDTSCP .
У старых чипсетов в итоге дойдёт до RDTSC — а пока дойдёт это уже дорого, и еще привет кучи багов, с которыми не раз боролся, когда таймстэмп надо было из разных потоков отмечать.
Ф>Такое поведение в абсолютном большинстве случаев.
Если дрова на чипсет нашлись — будет поставлено устройство high precision event timer.
В общем, не спорьте.
Если охота брать дешевое время — это GetTickCount64.
Здравствуйте, vdimas, Вы писали:
v> Ой, блин, из глаз кровь читать эту чушь. v> Плюс требуется запрашивать QueryPerformanceFrequency, а она у процов тоже гуляла постоянно.
А чушь писать ничего не кровоточит?
The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached.
