A Korean friend asked my wife if our son had celebrated Baegil or 100 days yet. Not being familiar with the celebration, we said that we hadn’t kept track of the days since his birth. I decided to write a little program in Go in order to check what day of one’s life one is currently on.
The program should take the subject’s date of birth as a string from the first command argument. This was simple enough for me to decide against using the flags package and check the command line arguments directly:
if len(os.Args) == 1 {
os.Stderr.WriteString("Please tell me your date of birth!\n")
} else {
...
}
I wanted to save programming effort and avoid reinventing the square wheel by using a library for handling the dates. The time package from the standard library can represent times and parse strings to time structs.
The time package has a peculiar (but easy to grok) way of specifying date layouts for formatting. Rather than %Y, %h, %s and so on from the standard C library and its descendants, in Go a fixed date where days are 1 and months are 2 and so on is used. So, to parse dates such as “2016-06-20” or “1980-10-28”, we need:
var layout = "2006-01-02" var dateOfBirth, dOBParseError = time.Parse(layout, os.Args[1])
Full details can be found on this blog post:
https://pauladamsmith.com/blog/2011/05/go_time.html
Of course, a user of the program might not enter a parseable date string, so we need a little bit more error handling:
if dOBParseError != nil {
fmt.Fprintf(os.Stderr, "Unable to parse your date of birth: %s\n", dOBParseError)
} else {
...
}
Once we have a date of birth, we can perform our arithmetic. The time package has a Since(...) method that can give you the duration of time since a given time struct:
var age = time.Since(dateOfBirth)
For a simple program like this, methods like Since are more convenient than creating a date object of the current time and comparing the given time to it. However, this does create an issue when testing code that does anything to do with time. If your code makes direct use of the system’s clock, your functions are impure as the same input won’t always return the same output. How do you test that a given input produces the correct output? Such tests would only pass at specific times on a given date. The purely functional way to do this is to write your business logic handling functions to accept all the used time objects already created, so that appropriate mocks can be passed in during tests without calling any methods that get data from the system’s clock. Another approach is the override the methods that call the system’s clock so that they return a set time in the test. This is called monkey patching. I’ve heard of people even setting the system clock during the test, but this is likely to have unforeseen consequences, especially on a shared build server.
The time package defines an Hours function for Duration structs but not one for days. A quick and dirty solution to this is the divide the number of hours by 24 and floor the result:
var ageInDays = math.Floor(age.Hours() / 24)
This makes the assumption that every day has exactly 24 hours. What about leap seconds? A person might have a few leap seconds during a lifetime. What if this program is run within a few seconds of midnight? The result might be different from the true result. As we are not using the precise time of birth and are flooring the number of days anyway, this is not too much of a concern. However, if really precise maths is needed or you using the components of one time struct to create a new time struct, inaccuracies can creep into your code. The fun really begins when you need to handle issues like leap years, time zones and seasonal time adjustments. If I ran this code in San Francisco in Winter for someone who was born in Sydney during Daylight Saving Time, would the result be accurate? A more fully developed version of this program would probably use a library to handle the mind boggling complexity of time tracking in the real world.
Another issue to consider is off by one errors. I’m flooring the number of days in order to say, “days since”. If I enter today’s date, I will get 0 as the subject’s age has not reached one day yet. This might be confusing to someone expecting 1 on the first day and so on. How ages are reckoned changes among different cultures. How Koreans consider their ages is surprising to many foreigners.
https://en.wikipedia.org/wiki/East_Asian_age_reckoning#Korean
Koreans celebrate Baegil on the 100th day, so we would expect the program to return 99 on the appropriate day. A programmatic solution to this might be add 1 to the result and change the wording. Programmers need to consider the audience of their programs carefully and gather requirements fully.
Obviously, you can’t be born in the future and still use the program, so we need a bit more user input checking:
if ageInDays < 0 {
os.Stderr.WriteString("Wow! I must be talking to a foetus!\n")
} else {
...
}
If we’ve made it this far, we can now print the age in days:
fmt.Printf("Days old: %.0f\n", ageInDays)
Putting it all together, this is my program:
package main
import (
"fmt"
"math"
"os"
"time"
)
func main() {
if len(os.Args) == 1 {
os.Stderr.WriteString("Please tell me your date of birth!\n")
} else {
var layout = "2006-01-02"
var dateOfBirth, dOBParseError = time.Parse(layout, os.Args[1])
if dOBParseError != nil {
fmt.Fprintf(os.Stderr, "Unable to parse your date of birth: %s\n", dOBParseError)
} else {
var age = time.Since(dateOfBirth)
var ageInDays = math.Floor(age.Hours() / 24)
if ageInDays < 0 {
os.Stderr.WriteString("Wow! I must be talking to a foetus!\n")
} else {
fmt.Printf("Days old: %.0f\n", ageInDays)
}
}
}
}
Entering my son’s date of birth, I see that we still have a couple of days to go:
$ ./daysOld 2016-06-20 Days old: 97
The source code can be found at:
https://github.com/robert-impey/CodingExperiments/blob/master/Go/daysOld.go
Reversing Entropy 