v1.0.0.6

Version 1.0.0.6:

To resolve (Issue 24), add Parse and TryParse methods to parse stringified PortableMonotonicTimestamps and PortableDurations. These methods only work with values stringified via the default ToString() methods.

Added unit tests for the methods.

Unit test application now enables the nullable reference type feature.

Version 1.0.0.4:

This release fixes two bugs.

First (see Issue 21), it fixes a bug where using monotonic timestamps close to the extreme values (within a month or so of 1-1-0001AD and 12-31-9999AD) was causing overflow in .NET 5.0. The fix increased the buffer around the min/max values so that overflow does not occur in .NET 5.0. You may have to alter your uses if you were (for some reason) storing portable monotonic stamps close to the extrema of permissible values.

Second (see Issue 22), it fixes a bug where subtracting a portable duration from a portable monotonic stamp was executing addition, not subtraction.

Finally, please note that unit test applications, example code and test application are now all built and run against .NET 5.0 rather than .NET Core 3.1.

Version 1.0.0.2:

This release fixes a bug (see Issue 19) where the PortableDuration type's FromDays factory methods (and perhaps other From factory methods taking a double as a parameter) used incorrect math and incorrect validation logic.

Version 1.0.0.1:

This release contains no changes to the code itself or to program behavior. Instead it merely fixes the repository url to refer to the source repository rather than the http page that hosts the Github repository. Also, it enables the nuget package to be built deterministically.

Version 1.0.0.0:

This is the non-beta release of the fix introduced with beta version 0.1.1.0-beta. The issues resolved by that release included problems with serialization and deserialization of portable monotonic stamps when serialized on a system with a different DateTime.MinValue.ToUniversalTime() value than the one on which it is deserialized. Those changes are discussed in pull request 14, issue 12 and issue 13. The changes to the code can be reviewed in pull request 14, commit x and, most particularly around these lines of code.

v1.0.0.4

Release Notes

Version 1.0.0.4:

This release fixes two bugs.

First (see Issue 21), it fixes a bug where using monotonic timestamps close to the extreme values (within a month or so of 1-1-0001AD and 12-31-9999AD) was causing overflow in .NET 5.0. The fix increased the buffer around the min/max values so that overflow does not occur in .NET 5.0. You may have to alter your uses if you were (for some reason) storing portable monotonic stamps close to the extremes of permissible values.

Second (see Issue 22), it fixes a bug where subtracting a portable duration from a portable monotonic stamp was executing addition, not subtraction.

Finally, please note that unit test applications, example code and test application are now all built and run against .NET 5.0 rather than .NET Core 3.1.

Version 1.0.0.2:

This release fixes a bug (see Issue 19) where the PortableDuration type's FromDays factory methods (and perhaps other From factory methods taking a double as a parameter) used incorrect math and incorrect validation logic.

Version 1.0.0.1:

This release contains no changes to the code itself or to program behavior. Instead it merely fixes the repository url to refer to the source repository rather than the http page that hosts the Github repository. Also, it enables the nuget package to be built deterministically.

Version 1.0.0.0:

This is the non-beta release of the fix introduced with beta version 0.1.1.0-beta. The issues resolved by that release included problems with serialization and deserialization of portable monotonic stamps when serialized on a system with a different DateTime.MinValue.ToUniversalTime() value than the one on which it is deserialized. Those changes are discussed in pull request 14, issue 12 and issue 13. The changes to the code can be reviewed in pull request 14, commit x and, most particularly around these lines of code.

Version 1.0.0.2

Version 1.0.0.2:

This release fixes a bug (see Issue 19) where the PortableDuration type's FromDays factory methods (and perhaps other From factory methods taking a double as a parameter) used incorrect math and incorrect validation logic. The primary part of the fix can be viewed here.

Official Release v1.0.0.1

This minor release provides an improved nuget package. The nuget package is now:

• Built deterministically
• Contains metadata that correctly refers to the source repository rather than its html github web page.

Official Release v1.0.0.0

This is the non-beta release of the fix introduced with beta version 0.1.1.0-beta. The issues resolved by that release included problems with serialization and deserialization of portable monotonic stamps when serialized on a system with a different DateTime.MinValue.ToUniversalTime() value than the one on which it is deserialized. Those changes are discussed in pull request 14 1, issue 12 2 and issue 13 3. The changes to the code can be reviewed in pull request 14 1, commit x 5 and, most particularly around these lines of code 6.

Beta release: fix problems with portable timestamps.

Note:
This library is available as a nuget package (including symbols) and can be downloaded from nuget here or installed by searching for it using the NuGet package manager. The nuget package and symbols are also included in the .7z attached to this release. Also in the .7z, you can find binaries for the test application, unit tests, demonstration application and other utilities.

Release Note (v0.1.1.0-beta):

This beta release fixes a major problem with Portable Monotonic stamps being serialized and deserialized on different systems. Apparently, the min value of DateTime.ToUniversalTime can differ from system to system. Moreover, it does not seem always to be an offset around the non-daylight savings time utc offset of the current timezone: indeed, I have seen different platforms on the same timezone vary by an odd number of minutes. I am unsure why this is. The result was that a portable monotonic stamp serialized on one platform, then deserialized on another would be interpreted differently leading to a discrepancy in the values by sometimes bizarre amounts. This was resolved by adding a string field to the Portable Monotonic stamp that is set during the OnSerializing callback. When the stamp is deserialized, the string --if present-- is parsed into a portable monotonic stamp and the internal fields are adjusted accordingly. If you were only serializing/deserializing these on similar systems in the same time zone, this fix should not affect you. Going forward, serialized portable stamps will have both the nanoseconds offset field and the stringified field. After this beta is tested as used in software I maintain, I will release a non-beta version.

Initial Release

Status of Testing / Project

I have used this library to good effect in many projects. It requires more unit tests and there will doubtless remain bugs. It is, however, essentially feature complete and has been unit tested on four different systems:

1. A Windows 10 System with a Stopwatch frequency of 10,000,000 ticks per second.
2. An Ubuntu 20.04 system with a Stopwatch frequency of 1,000,000,000 ticks per second.
3. An Amazon Linux 2 (based on CentOS) system with a Stopwatch frequency of 1,000,000,000 ticks per second.
4. An Amazon Workspaces Window Server (Windows 10 based Windows server) with (most vexingly) a stopwatch frequency of 2,441,366 ticks per second.

I have decided to make this version a release despite knowing that there remain bugs (but having used the project extensively myself) and a need for additional unit tests because I believe it is in a useful, though imperfect, state. Please inform me of any bugs found on the issues page or via email: I intend to fix bugs. I consider this project more or less feature complete and do not imagine any additional extensive features being added by me. If you would like to add features, I am happy to review any pull-request or issue.

Beta Release v0.0.5.4

This release resolved some major problems with int128 arithmetic. Now the code is based on the work of Google/Abseil in their C++ int128 library. Also, multiplication and division are now faster. Unit test project significantly updated. Unit test utility written in C++ that generates Int128 operations and their results using Abseil, which the C# unit tests use to verify that the calculations produce the same value. The unit test utility is not very user friendly at this point, but is really only intended to produce data the C# unit test project can use.

Unit Tests and Many Bugs Fixed

Unit tests have been added and many bugs uncovered and fixed as a result. Primary source of difficulty was that on some systems there can be (unexpectedly) very strange frequencies for the stopwatch clock. On my home workstation the monotonic clock has a frequency of 10,000,000 ticks per second, just like TimeSpan. On my linux testing environment (Amazon Linux 2), the monotonic clock has a duration of 1,000,000,000 ticks per second. Neither of these values proved problematic. On my secondary Windows testing system (an Amazon AWS Workspace), the monotonic clock frequency was 2,441,367 ticks per second: less precise than TimeSpan -- though presumably more accurate. It was on this system that many of the bugs were uncovered.

Breaking changes include:

• renaming a misspelled namespace from HpTimesStamps -> HpTimeStamps.
• discovering that all conversions -- both TimeSpan and PortableDuration to and from duration should be considered potentially narrowing. Thus, implicit TimeSpan -> Duration, Duration -> TimeSpan, Duration -> PortableDuration and Duration -> PortableDuration all require explicit casting for conversion as of this release. TimeSpan's frequency is supposed to be invariant @ 10,000,000 ticks per second and Portable Duration's frequency is by design invariant at 1,000,000,000 ticks per second (i.e. nanoseconds resolution. Conversion from TimeSpan to PortableDuration, therefore, remains widening only and therefore implicit. PortableDuration to TimeSpan is of course narrowing and remains explicit.
• Hopefully this will be the last breaking change that will require refactoring on the part of client code. It is likely there will be binary breaking changes in the future requiring recompilation but I hope to avoid any changes that force client code to refactor.

Change backing field for duration to Int128

Size will accommodate entire datetime range even if frequency of Stopwatch ticks has nanosecond resolution.