Is DateTimeOffset.MaxValue.ToUnixTimeMilliseconds() stable?

Question

I am trying to use DateTimeOffset.MaxValue.ToUnixTimeMilliseconds() (which is 253402300799999) to designate a maximum value for some data.
This time basically represents "never" or that it was not set. I could also use a nullable DateTimeOffset, but I would prefer not to, as it will introduce null checks all over the codebase.

I need to do comparison and equality checks on instances of these times.
Since I need to do comparison on these after they have been changed to a long, it is important for me that DateTimeOffset.MaxValue.ToUnixTimeMilliseconds() is stable.
In other words, it needs to always be equal to 253402300799999. Can I be guaranteed it is, even if leap seconds are added or subtracted sometime in the future?

P.S. For various reasons, NodaTime or similar libraries are not an option in this case.

Answer 1

TL;DR; - Yes, that value is stable and is very unlikely to change in future versions.

As the value of DateTimeOffset.MaxValue is documented - it's very unlikely it will change in the foreseeable future.

The remarks section of DateTimeOffset.MaxValue Field official documentation clearly states:

The value of this constant is 12/31/9999 11:59:59 PM +00:00.

Also, ToUnixTimeMilliseconds is documented to return the number of milliseconds passed since January 1st 1970 exactly at midnight (which is the unix epoch).

It's remarks section clearly states it doesn't calculate leap seconds:

Unix time represents the number of seconds that have elapsed since 1970-01-01T00:00:00Z (January 1, 1970, at 12:00 AM UTC). It does not take leap seconds into account. This method returns the number of milliseconds in Unix time.

However, if you choose not to trust official documentation, you can pick any random future date as your "never" (or "always") point - as long as it's far enough, you're consistent about it and use a reasonable constant name for it in your code. Personally, I like to use January 1st, 2525 for that purpose.