See the version list below for details.
NuGet\Install-Package HighPrecisionTimeStamps -Version 0.0.4-beta
dotnet add package HighPrecisionTimeStamps --version 0.0.4-beta
<PackageReference Include="HighPrecisionTimeStamps" Version="0.0.4-beta" />
paket add HighPrecisionTimeStamps --version 0.0.4-beta
#r "nuget: HighPrecisionTimeStamps, 0.0.4-beta"
// Install HighPrecisionTimeStamps as a Cake Addin #addin nuget:?package=HighPrecisionTimeStamps&version=0.0.4-beta&prerelease // Install HighPrecisionTimeStamps as a Cake Tool #tool nuget:?package=HighPrecisionTimeStamps&version=0.0.4-beta&prerelease
High Precision Timestamps
A timestamp utility used by my other projects superior for my use-cases to use of DateTime.Now.
This project provides high precision timestamps (calibrated on a per-thread basis and periodically synchronized with system clock) that is very useful for obtaining DateTimes which when subtracted from other DateTimes obtained on the same thread within the same period provides a useful delta. The source is the stopwatch, which uses a high performance event counter, if available. Also, rather than just using the tick count, it allows the timestamp to serve as a readable and relatable timestamp in event logs. It should not be used for timestamps that users rely-on to have a high degree of accuracy vis-a-vis local time, but, in most cases, can be quite accurate. When considering two such DateTimes obtained within a (short) calibration period of each other on the same thread, the elapsed difference between themselves should be as accurate as the machine's high precision event timer.
Another utility herein is the monotonic timestamp. This also uses Stopwatch ticks but is calibrated once at startup for all threads. A monotonic clock never goes backwards, unlike a system clock (subject to user adjustment, daylight savings time, synchronization with a time server, leap seconds etc). These stamps store an offset in stopwatch ticks from the reference time (readonly static value computed first time stamp provider is activated). Thus, these stamps can be understood to be monotonic ticks elapsed since a reference time. They can also be converted into date time for storage as timestamps but, since calibrated once only, drift between the monotonic clock and system clock (in addition to changes to system clock) may make their timestamps misleading over time. These values cannot be serialized as-is (because they rely on static readonly in-process state to derive their semantic meaning). They can be converted to DateTimes but be wary of the issues I have described. At a future time I may provide an "archive" format for these to allow them to be saved or serialized. Understood as monotonic ticks since a reference datetime, these are superior to the high precision stamps. Also, the value contains only a long (the calibration data, again, is static) so recording the stamp and comparisons / arithmetic is quick. String conversions, extracting date times may be slower but it is more important to record and compare quickly than to log, print, output quickly for my use cases.
This project is currently used by me in other projects where it has proved useful for the particular ways it is employed in those projects. Extensive pan-use case testing has not been performed. There is a basic console test application on the source page for this project on GitHub. Eventually I may test this more extensively and document it more rigorously but that is not high on my priority list right now: it works well for what I use it for. If you would like to help get this into "general use library shape", contact me.
|.NET||net5.0 net5.0-windows net6.0 net6.0-android net6.0-ios net6.0-maccatalyst net6.0-macos net6.0-tvos net6.0-windows|
|.NET Core||netcoreapp2.0 netcoreapp2.1 netcoreapp2.2 netcoreapp3.0 netcoreapp3.1|
|.NET Standard||netstandard2.0 netstandard2.1|
|.NET Framework||net461 net462 net463 net47 net471 net472 net48|
- JetBrains.Annotations (>= 2020.1.0)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on HighPrecisionTimeStamps:
Synchronization Library and Static Analysis Tool for C# 8 DotNetVault is a library and static code analysis tool that makes managing shared mutable state in multi-threaded applications more manageable and less error prone. It also provides a common abstraction over several commonly used synchronization mechanisms, allowing you to change from one underlying type to another (such as from lock free synchronization to mutex/monitor lock based) without needing to refactor your code. Where errors do still occur, they are easier to locate and identify. The project description (a detailed design document) can be read here: https://github.com/cpsusie/DotNetVault/blob/master/DotNetVault_Description_v1.0.pdf. A quick start guide for installation (Windows, Vs 2019+) can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/QuickStart_Install_VS2019_Windows.md. A quick start guide for installation (Tested on Amazon Linux, Rider 2019.3.1+) can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/Quick_Start_Install_Rider_Amazon_Linux.md. A guided tour / quick start guide for this project's functionality can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/Quick_Start_Functionality_Tour.md
This package is not used by any popular GitHub repositories.
Duration type is now backed by a 128 bit integer to facilitate entire range of DateTime struct where frequency of stopwatch is 1 tick / nanosecond.
Focus is now on the monotonic stamps.
Added a duration type analogous to TimeSpan but matching the frequency of stopwatch rather than timespan. This allows computations to be made without rounding errors. duration's backing field will probably be changed to a Int128 once I find one written in a relatively modernish style of C# that will not require massive importation of dependencies. The problem was detected when testing on a linux machine where the stopwatch frequency was 1,000,000,000 rather than 10,000,000 as in windows -- adding a timespan to produce new stamp and then subtracting same produced distinct values due to round-off.
Monotonic Timestamps work both as UTC and Local (by nature).
Test cases added for monotonic stamps.
TimeStampSource.UtcNow probably does not work and has not been tested.