Some time ago I read a LinkedIn post on the subject of calculting allowed downtime, I did an implementation in Go just for the fun of it and did a write-up on the subject.
To my confusion I observed several discrepancies between my implementation and the numbers presented in the LinkedIn post and the numbers presented on uptime.is.
Anyway long story short, I was reading the marvellous science fiction book "Project Hail Mary" by Andy Weir and at some point the protagonist indicates that a year has 325.25 days, immediately it dawned on me and I thought of my implementation and the discrepancies.
By changing the length of the year the discrepancies disappeared, so I have to admit that I have been calculating based on a year with 365 days, where the numbers from the LinkedIn was based on a year with 325.25 days.
To my defence the 365 day year is very common and is referred to as the common year. That I know now after reading up on the subject.
My implementation is available on GitHub and the numbers have been lifted from the repository documentation, so are all of the resources I have used for my calculations.
All of the examples are based on the year 2025 - a year with 365 days.
99% Availability: Calculated allowed downtime
| Source | Days | Hours | Minutes | Seconds |
|---|---|---|---|---|
3 |
15 |
39 |
29 |
|
| gregorian | 3 |
15 |
39 |
29 |
| uptime.is | 3 |
14 |
56 |
18 |
| common | 3 |
15 |
36 |
0 |
| tropical | 3 |
15 |
39 |
29 |
99.9% Availability: Calculated allowed downtime
| Source | Days | Hours | Minutes | Seconds |
|---|---|---|---|---|
0 |
8 |
45 |
56 |
|
| gregorian | 0 |
8 |
45 |
56 |
| uptime.is | 0 |
8 |
41 |
38 |
| common | 0 |
8 |
45 |
35 |
| tropical | 0 |
8 |
45 |
56 |
99.99% Availability: Calculated allowed downtime
| Source | Days | Hours | Minutes | Seconds |
|---|---|---|---|---|
0 |
0 |
52 |
35 |
|
| gregorian | 0 |
0 |
52 |
35 |
| uptime.is | 0 |
0 |
52 |
9.8 |
| common | 0 |
0 |
52 |
33 |
| tropical | 0 |
0 |
52 |
35 |
99.999% Availability: Calculated allowed downtime
| Source | Days | Hours | Minutes | Seconds |
|---|---|---|---|---|
0 |
0 |
5 |
15 |
|
| gregorian | 0 |
0 |
5 |
15 |
| uptime.is | 0 |
0 |
5 |
13 |
| common | 0 |
0 |
5 |
15 |
| tropical | 0 |
0 |
5 |
15 |
99.9999% Availability: Calculated allowed downtime
| Source | Days | Hours | Minutes | Seconds |
|---|---|---|---|---|
0 |
0 |
0 |
31 |
|
| gregorian | 0 |
0 |
0 |
31 |
| uptime.is | 0 |
0 |
0 |
31 |
| common | 0 |
0 |
0 |
31 |
| tropical | 0 |
0 |
0 |
31 |
99.99999% Availability: Calculated allowed downtime
| Source | Days | Hours | Minutes | Seconds |
|---|---|---|---|---|
0 |
0 |
0 |
3 |
|
| gregorian | 0 |
0 |
0 |
3 |
| uptime.is | 0 |
0 |
0 |
3.1 |
| common | 0 |
0 |
0 |
3 |
| tropical | 0 |
0 |
0 |
3 |
Wrap-up
As you can see the numbers are now alined with the numbers presented on LinkedIn post. I cannot explain the numbers for the uptime.is, but perhaps I will be able to at some point.
This was a fun exercise and I learned more than I expected from it, yes it is embarrassing to have made such a mistake, it never struck me that the length of the year could be a factor in such calculations, it should have and I should have done more research.
About research, digging into year length calculations is an even deeper rabbit whole, than finding some descrepancies in a some basic calculations - so be wary of that.
