Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix two quick typos in readme #1

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix two quick typos in readme #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,15 +45,15 @@ All supported types have 100% code coverage because I dont want to ever have to

Please Note: 100% code coverage in GoLang code is not a guarantee of a lack of bugs in GoLang code. This is in part due to GoLang's poor design mistakes when it comes to the "time" module.

One of the biggest issues many have with GoLang is that GoLang handles time formatting badly, using arbitrary format strings and date values that are, strictly speaking, not always compatiable with the worlds standards on issues of time.
One of the biggest issues many have with GoLang is that GoLang handles time formatting badly, using arbitrary format strings and date values that are, strictly speaking, not always compatible with the worlds standards on issues of time.

This is a known issue that will create issues in the future for users of this library after I have been dead for a few thousand years... but as this is known issue, with known problems, I felt that simply getting this module to 100% code coverage was enough on my end as a consumer of these time api's to have done my due diligence as an engineer.

Yet as an engineer, I need to bubble up the risk, and communicate that trade off, summed up as follows, because GoLang has commited itself publicly to backward compatability:

Good: This library can work flawlessly for thousands of years using integer based constants, having been unit tested and fully proven in 100% of every possible tested case to be accurate and complete for that time.

Bad: After I have been dead for several thousand years, this library may still exist long enough that it would reach a time period that will create issues for its users due to solar clock drift and the overflowing nature of time itself. At that time, it might need a single line of code updated after a few thousand years of perfect utility, to mitgate a small defect in the golang time module.. unless they allready fixed it by then.
Bad: After I have been dead for several thousand years, this library may still exist long enough that it would reach a time period that will create issues for its users due to solar clock drift and the overflowing nature of time itself. At that time, it might need a single line of code updated after a few thousand years of perfect utility, to mitgate a small defect in the golang time module.. unless they already fixed it by then.

# How to Run The Unit Tests With coverage On Windows Using Standard GoLang

Expand Down