A movie that went from her childhood through her days in school to quitting school, racing, opening her store and becoming a hardware engineer up to her recent successful funding would be great. Plus we can always have a second movie for what she does later instead of yearly reboots like those Steve Jobs biopics. Pirates of Silicon Valley was completed before the release of the iPhone, right?
So what's a better time library?
Or, rather, how could Go's time library better accommodate these things?
It's also not clear that a standard library time package should be the be-all, end-all time management solution. I don't see any reason for a standard time package to handle historical dates, for example.
Google found a nice solution to the leap second issue: we "smear" the second over the day before it occurs by making tiny changes to the time over the day. This means user applications don't need to be aware of it: http://googleblog.blogspot.com.au/2011/09/time-technology-an...
The power grid people do that, but after the leap second. It takes about four hours, as every 1800 RPM synchronous motor and generator on the grid makes 30 extra turns.
I was going to mention the same thing wrt leap seconds: if a company at Google's scale could apply a "hacky" solution to this, then you don't really need a more "scalable" solution. The fact that it simplifies things massively for the developers can be a turn off for some people, though.
You've got it backwards: a company of Google's scale can do this because they're already providing and administering their own NTP servers. For a company of a smaller scale, that's an unnecessary cost.
That said, I'm intrigued at the idea of a public NTP server that does Google-style leap-second smearing. Does anyone know if one exists?
All the Network Time Protocol servers that I know of handle leap-seconds in one way or another. Some do leap-second smearing and I believe that newer versions of NTPD and OpenNTPD both support smearing. However, it appears (with only a cursory examination) that the Google time servers start smearing before the actual leap second is inserted and I've never seen that done anywhere else (or I missed it by reading too quickly).
Also note that big changes in the way time is handled (leap seconds, etc.) in the near future because of the upcoming meeting of the International Telecommunication Union (ITU) at the World Radiocommunication Conference in November 2015.
The ITU has 4 methods for dealing with leap seconds, and method D is to change nothing. See the lack of consensus for any change in last week's presentations at
http://www.itu.int/en/ITU-R/conferences/wrc/2015/irwsp/2015/...
especially the "Input Document WRC-15-IRWSP-15/8" presentation by Zuzek.
Oh I see. Sorry. I didn't mean it to come across like that. Just had a recent personal situation I'd rather not go into on a public forum that would have turned out a whole lot better if me and the truth were more in alignment, sad to say : / Anyway, one lie begets another. Just tell the truth, less cognitive overload, less trust issues. Easier said than done I know; we all want to save face, we all have our shame to hide.
I'd say if you can't trust each other in a long term relationship, you have no business being in that relationship. You're in it to support each other. This is a situation where you need support.
Even so, the rarity of a card is simply a measurement of how many of that type of card are produced. There are not, for instance, some uncommon or rare cards printed with different text or statistics from the common version of the same base card. (The idea is intriguing, though!)
> Does anyone else feel like 1.5 was released prematurely before it was honestly ready to go out the door? At this point Go is more than 5 years old; these kinds of amateur issues seem unacceptable.
Honestly, no. All software has bugs. The Go codebase is very solid, in general. It's hard to get away with as much change as we've had between 1.4 and 1.5 without a few issues slipping through.
At Google we've been running 1.5 in production for a while and didn't catch this issue. As have a lot of our other users. But inevitably when you release the stable version more bugs are uncovered; this is just life.
Conservative users should certainly wait a few days (or weeks) after a major new version before upgrading. Historically we have released version 1.N.1 within a couple of weeks of each major release. If I were you I'd just wait for 1.5.1.
edit: I think "very nasty" is overstating things. The likelihood of real code triggering this bug is extremely low.