Every dev knows that working with dates and times sucks. Common knowledge holds that this is because dates are a human construct, and that devs make bad assumptions, like "there are 365 days in a year" or "there are 24 hours in a day" or "there are 60 seconds in each minute." And this is true! But it's also the case that devs have been done dirty by datetime libraries that don't let you be specific about what you're talking about.
Every time a Javascript date-picker returns a Date object, I die a little bit, because it's actually returning a date + time + timezone, and then it's left up to convention how to interpret this. Should the date be midnight in the local time zone? Should it be in UTC? Should it be at noon in the local time zone to maximize liklihood that the date portion will be the same in both local and UTC time zones? I've seen all three!
Java's time library fixes this. It follows the JSR 310 spec, largely based on the Joda-Time library which comprehensively lays out all of the different things that you might be talking about when you ask what time it is.
you do not want to know how the Go datetime library works
