A New Spin on the Quantum Brain - <AUTHOR> https://www.quantamagazine.org/20161102-quantum-neuroscience/ <comment><USER4> The piece[1] from John Preskill linked in the article has less fluff and is more informative, IMO.

Given Preskill is director of the IQIM, and Fisher is on its faculty, he may have a promotional agenda; but he has an impressive pedigree[2] - I don't have the knowledge to directly evaluate the hypothesis myself, but if Preskill considers it worth investigating, I'd refrain from betting that it's nonsense!

1: [https://quantumfrontiers.com/2015/11/06/wouldnt-you-like- to-...](https://quantumfrontiers.com/2015/11/06/wouldnt-you-like-to-know- whats-going-on-in-my-mind/)

2: [https://en.m.wikipedia.org/wiki/John_Preskill](https://en.m.wikipedia.org/wiki/John_Preskill)

<comment><USER5> Thanks for the link.

I just watched [https://www.youtube.com/watch?v=ku6jVUJONZAm](https://www.youtube.com/watch?v=ku6jVUJONZAm) which is a recent lecture in which Matthew Fisher goes into some detail for a predominantly physics theorist audience. He doesn't actually finish his whole talk, but what he does cover is still pretty interesting to me as someone just trying to follow along with my rudimentary recollections of college quantum mechanics.

So {ortho,para}-pyrophospate is a big part of his grand hypothesis. This is analogous to {ortho,para}-water, something I hadn't heard about but which is apparently pretty famous, except with phosphorous instead of hydrogen. And as part of discussing this he mentions a study, presumably [http://www.biophys.ru/archive/h2o-00011.pdf](http://www.biophys.ru/archive/h2o-00011.pdf), that claims that passing water vapour through charcoal can change the ortho/para ratio from the normal 3:1 to 12:1 and then down to 2:1 for _hours_. That's just amazing to me, that liquid water can effectively remember a prior interaction for hours. Like that Japanese crank scientist's claims about water memorizing poetry or something, but, you know, actually real.

Fischer's proposed explanation is that ortho-water (and orth-pyrophospate) can't "sit still" because of the way that the aligned nuclear spins of the hydrogen (phosphorus) atoms cause the angular momentum to be quantized in a way that locks the angular velocity to be non-zero. And that discourages the ortho-molecule from being adsorbed or participating in catalysis -- measurable things which can clearly have biological effects. And from the nuclear spin, which is otherwise very long lived!

That's just crazy! Metastable water lasting for hours? I just smiled.

The other stuff may even be a red herring, but even this basic idea is so exciting if true. Here's a suggestive quote from the Russian article:

> Ortho and para water are expected to have notably different physical- > chemical properties and, like ortho and para hydrogen, have different > magnetic properties. The absence of the magnetic moment in para modification > implies its complete insensitivity to the magnetic field, which could be of > use in magnetic resonance imaging. The OP separation procedure realized is > quite straightforward and may occur in nature—in soil, atmosphere, living > organisms, and cosmic objects. The scope and the role of this phenomenon are > yet to be studied.

<comment><USER5> For posterity, some non-reproductions of the Russian paper:

[http://link.springer.com/article/10.1134/S1063776106010092](http://link.springer.com/article/10.1134/S1063776106010092)

[http://journals.aps.org/pra/abstract/10.1103/PhysRevA.85.012...](http://journals.aps.org/pra/abstract/10.1103/PhysRevA.85.012521)

</comment></comment></comment><comment><USER6> If there were some quantum process involved in our neurons, the next question would be, when did it evolve? Is it in sponges? We actually have quite complete simulations of neural networks of some lower lifeforms. It must have then evolved sometime between the lifeforms we can simulate and ourselves. If that's the case, you'd expect some discontinuity in functionality vs volume. You don't see that anywhere.

And as stated in the article, it seems to be a solution in search of a problem.

<comment><USER7> It mostly seems to be another place for dualists to hedge their bets, without a whole lot to offer anyone else. Maybe that will change, but I doubt that will be anytime soon.

<comment><USER6> Really a poor place too, since we can simulate quantum behavior, albeit inefficiently.

</comment></comment></comment><comment><USER8> I'm basically pro quantum-brain (being honest about my bias here) but am fairly pessimistic about our ability to actually detect such processes in the brain. It's such an interesting question though, and this is what motivated me to do a PhD in quantum information theory. Our ability to detect entanglement is at the moment extremely rudimentary. It appears that detecting entanglement is about as difficult as creating entanglement, and we suck at this also. Most of the proposals for quantum computing require vast amounts of entanglement, and in such a way that any observation of a small sub-part of the system cannot detect the encoded information. So, we may need a quantum computer to be able to detect a quantum computer.

<comment><USER9> Well, save some immense breakthrough, _we_ won't detect anything, that's for sure. That's why it's so important to live, work, educate in a sustainable fashion ;) . Let's face it, we don't know a whole lot about anything. Thankfully, many people are taking up the challenge. Sadly, many, many more just don't get it. Sorry for this rant, it's late.

</comment></comment><comment><USER10> I've long suspected that the brain might be using quantum computing techniques. It's a good physically plausible explanation for how you can get more compute than a modern at-scale data center on 40-60W of power and in a volume about the size of two beer cans.

IMHO there's really only three possibilities:

(1) There exist ridiculously efficient learning, search, and other algorithms that have not been formally discovered that allow the brain to do what it does on a lot less compute than we think. P=NP would be the extreme case of this.

(2) The brain is a quantum computer or is doing something equally exotic.

(3) It's supernatural, and the brain is only like a radio receiver for something in another realm. (Or the universe is a simulation, etc., etc.)

<comment><USER11> Or (4) the brain uses specialized electrochemical processes to perform computations that are not well addressed by traditional computing paradigms, which are designed to outperform the brain in areas in which it is naturally weak.

<comment><USER10> I think this is a variant of (1). Anything like this should be able to be computationally approximated efficiently.

<comment><USER11> Why? That claim seems baseless to me.

My GPU can compute things efficiently that my CPU can't, and vice-versa. Historically, analog computers have been able to compute things efficiently that digital computes could not, and vice-versa.

Why should a digital computer be particularly adept at computing that which a dense electrochemical network can?

</comment></comment></comment></comment><comment><USER12> Crazy or not, the fact that he brings up testable hypothesis is reason enough for further study.

</comment><comment><USER13> The article makes it sound like "quantum decoherence" was the "daunting obstacle that has plagued microtubules" as a concept. This is a lie. What has plagued the concept is that there is no evidence for it whatsoever. Microtubules are a basic structural building block of a wide variety of cells, and they have not been shown to take part in information processing (apart from sometimes acting as rails for molecules to travel along), much less have they ever been demonstrated to have any kind of "quantum" effect. Articles like the one here are lying to you.

Quantum consciousness is a presuppositional pseudoscience that starts with the assumption that cognitive processes (or "consciousness" whatever that means) cannot possibly be of biochemical origin, and then works through different scenarios based on that until the proponents find one that can't immediately be discredited for a while. Just because something can't be disproven doesn't mean it's true though, not by a long shot.

Do quantum effects play a role in chemistry? Yes, where interactions between molecules and actual quantum phenomena are expected, for example as postulated for the chlorophyl molecule. But nothing in actual, serious neuroscience has so far suggested that neurons use "fragile quantum states" to compute anything.

It's also important to understand what the people proposing the different flavors of quantum quackery are actually saying: their thesis is that there is a metaphysical property called "consciousness" inherent to the universe itself, and that brains act essentially as antennas for this cosmic phenomenon. Despite the utter baselessness of these claims, people are still vigorously believing in this ever since Roger Penrose famously lost his mind to it and Deepak Chopra started selling esoteric books about it.

Quantum quackery is an insidious new age philosophy aimed at exploiting the willingness of humans to believe they are special and beyond the mundanities of the rest of the universe.

<comment><USER14> There's a difference between cognition and consciousness. It's generally accepted that cognition is caused by electrochemical processes in the brain, the exact details of which are still to be worked out. However, there's no generally accepted, or even widely accepted, theory of consciousness.

I think that consciousness might be necessary to make quantum measurements, though. So did Eugene Wigner. This suggests to me that consciousness might have something to do with quantum mechanics at a fundamental level. Exactly what the connexion is, I don't know. I don't think it's helpful to point to particular quantum processes (possibly) taking place in the brain and claim they cause consciousness, because that still wouldn't explain how quantum phenomena give rise to consciousness.

<comment><USER13> That's because consciousness - at least in the way it's being used here - <USER3> not a scientific term at all. What people think it might be isn't reason enough to postulate a hugely fantastical cosmological mechanism where so far none has been shown to exist.

I don't really protest against your belief per se, but since you're making claims about reality that are designed to sound scientific when they really aren't, I feel compelled to voice disagreement, unpopular as it might be in this environment.

<comment><USER14> > That's because consciousness - at least in the way it's being used here - <USER3> > not a scientific term at all.

It's not scientific because it concerns subjective experience, i.e. qualia, which are not measurable or observable by someone else. All an observer can do is to observe how the subject reacts. We could either leave consciousness to philosophers (who haven't got much further than Plato did), or expand science to include subjective experience.

> What people think it might be isn't reason enough to postulate a hugely > fantastical cosmological mechanism where so far none has been shown to > exist.

Agreed.

> I don't really protest against your belief per se, but since you're making > claims about reality that are designed to sound scientific when they really > aren't, I feel compelled to voice disagreement, unpopular as it might be in > this environment.

I'm not advocating any "new age" world view here. My position is similar to that of David Chalmers, namely that there is something which remains to be explained. I have no particular views on how.

</comment></comment></comment></comment><comment><USER15> > My cynical prediction is that if quantum-effects are part of the brain, it > will only be in a practical, philosophically-boring way.

> So they may be essential to basic plumbing shared by many species, but not > otherwise a game-changing factor for "consciousness" or "intelligence"

</comment><comment><USER16> This reminded me of talk by David Mermin, about Michael E. Fischer: an important statistical physicist and the father of Matthew Fischer, as they mention in the text.

As with almost everything David Mermin writes, I specially enjoyed this talk: "My Life with Fischer" [0]. In this talk he describes how great, but scientifically 'unforgiving', Michael Fischer was, and how he raised the standards and quality of work of those around him. If he has discussed this successfully at length with his father and if his upbringing instilled in him some of the qualities Mermin attributes to his father, Matthew Fischer should be on to something interesting.

Let me share some quotes from that speech:

"Wagner and I had tried to explain to Michael that an argument of Pierre's could be adapted to prove that there could be no spontaneous magnetization in the 2-dimensional Heisenberg model. I hadn't known Michael for very long at that point, and one of the first things I learned was that you should think twice before claiming to _prove_ something in front of a man who encourages postdocs to show that the free energy _exists_. He didn't believe a word of it. Spectral functions, indeed! How did we know those frequency integrals even converged? It soon became evident that we were dealing with a man who knew nothing about quantum field theory, didn't care one bit that he didn't, and was convinced that we would be better off ourselves to forget it. Immediately.

So in the face of this astonishing attack, we worked backwards, unbundling the result from the conceptual wrappings in which it was enshrouded by some of the great thinkers of the previous decade, peeling off layer after layer, day after day, in the face of unrelenting skepticism, until finally we had it down to a trivial statement about finite dimensional matrices.

And then an astonishing change took place. "Publish!" he practically shouted, "it's very important!" and having learned what it was like to be at the end of a Michael Fisher attack, I suddenly learned what it was like to have him on your side. Freeman Dyson came to town. Michael introduced us. "Mermin and Wagner have proved that there's no spontaneous magnetization in the 2-dimensional Heisenberg model," Michael proudly informed him, as Herbert and I basked in his admiration. "Of course there isn't." Dyson responded. "But they have _proved_ that there isn't" Michael insisted. One Dyson eyebrow may have moved up half a millimeter in response. No matter. I was hooked on arguing with Michael Fisher. My life would never be the same."

On Mermin and Ashcroft's textbook (one of the best in the field):

"One person, however, has influenced almost every chapter. Michael E. Fisher, Horace White Professor of Chemistrry, Physics, _and_ Mathematics, friend and neighbor, gadfly and troubadour, began to read the manuscript six years ago and has followed ever since, hard upon our tracks, through chapter, and, on occasion, through revision and re-revision, pouncing on obscurities, condemning dishonesties, decrying omissions, labeling axes, correcting misspellings, redrawing figures, and often making our lives very much more difficult by his unrelenting insistence that we could be more literate, accurate, intelligible, and thorough. We hope he will be pleased at how many of his illegible red marginalia have found their way into our text, and expect to be hearing from him about those that have not."

"What does Michael Fisher do when he checks into a hotel room for a night? He rearranges the furniture. He'll rotate the bed 90 degrees, put the TV in the closet to make more room on the desk, carry the desk over to the window to get more light. He is an inspiration to me. Often I find it valuable to ask myself at difficult moments, what would Michael do? This strategy is not to be confused with that of the "What Would Jesus Do?" movement, though a comparison can be interesting. Often the two questions can lead to quite different answers.

Let me give you a recent example of the benefits of asking "What would Michael do?" A few years ago I was at the annual meeting of the Danish Physical Society which took place at a small conference center south of Copenhagen. Each conferee had a little apartment with a tiny attic. Downstairs was a living room and bathroom. Up a narrow ladder was a built in bed in a room with no light. Since one used the apartment only at night this was an irritating arrangement. I don't know how Jesus would have coped, but it was pretty clear to me what Michael would have done. So I dragged the mattress and bedding down the ladder, remade the bed on the living room floor, and never climbed up to the attic again. This solution would not have occurred to me if I had not asked myself "What would Michael do?"

The next day various Danish conferees complained about the arrangement. Ah, I said, under such trying circumstances you should always ask yourself what Michael Fisher would do. That night the air was filled with matresses hurtling down ladders. I believe there is now a flourishing "What Would Michael Do?" movement among the Danish physicists."

[0] [https://arxiv.org/abs/cond-mat/0211382](https://arxiv.org/abs/cond- mat/0211382)</comment>


Traveling back in time could be possible - <AUTHOR> https://medium.com/starts-with-a-bang/how-traveling-back-in-time-could-really-physically-be-possible-b212517d01c9 <comment><USER2> Note that under our current understanding of General Relativity, wormholes will rapidly collapse under their own gravity so quickly that not even a single photon would be able to traverse it because it closes off.

There's a theoretical way to stabilize it: put 'exotic matter' in the middle. Unlike all other matter, exotic matter has a negative energy density. This is the same sort of matter that would be needed to create an Alcubierre warp drive.

Unfortunately, we don't have any idea how to go about creating exotic matter. The closest we've come is the Casimir effect, when a region between two very close conductive plates will in some ways act as if there were negative energy.

[1] [http://www.bibliotecapleyades.net/ciencia/negativeenergy/neg...](http://www.bibliotecapleyades.net/ciencia/negativeenergy/negativeenergy.htm)

<comment><USER3> > Unfortunately, we don't have any idea how to go about creating exotic matter

A priori, I don't see any reason to believe that creating it should be possible. It's never been observed, and I'm assuming there aren't any models which predict any methods by which it might come into existence. That's as good as saying it's made up to me.

</comment></comment><comment><USER4> I broke my rule of not reading medium articles, but how exactly does this prevent the grandfather paradox? Once you're back in time you can still stop yourself in the future from entering the worm hole...

<comment><USER5> Where's the paradox? Given that a person has already appeared out of nowhere - matter/energy has been created - I'd say that having someone with identical genetic make-up to them running around is minor stuff.

<comment><USER4> I exist in 2017. I go to 1978. I kill my other form before 2017 is reached. Therefore I cannot have traveled to 1978. What has occurred at each particualy moment is no longer consistent in a way that is clearly comprehensible by humans.

<comment><USER6> You have it backward.

The only reason you managed to live into 2017 is because all the assassinations on your grandparents failed.

The only thing that will happen if you try to go into 1978 is that you will discover why you failed.

<comment><USER4> Hahaha sure but this scifi scenario is orthogonal to the wormhole time travel mechanism.

</comment></comment></comment></comment></comment><comment><USER7> It's not clear what all the rules are and how this prevents the grandfather paradox.

What ever mechanism that prevents the paradoxical violations also makes this not very exciting (as far as time travel goes): you have to spend the "40 years" between you visiting one end of the wormhole and you entering the other at near-luminal velocity (hence you would only perceive it as 1 anyway). It's not so much "time travel" as an instant return ticket (where only your personal real time is spent, assuming your ship is exactly as fast as the one that carried the wormhole).

Which does actually have an interesting effect if you make them in pairs. It makes books like The Commonwealth Saga technically almost viable (e.g. where they build networks of portals and then just run trains through them non-stop to travel between worlds). Except that instead of using portals to explore new worlds, they would have to send a probe to those planets with a wormhole on board, at near the speed of light. And trips might cost you a bit of relative time to make a trip and return (e.g. the difference between the speed of light and the speed the probe delivered the wormhole from both portals added together would be how far in the relative future a trip would send you).

This all of course requires exotic matter which probably doesn't exist; which is why this whole thing probably doesn't work in the first place (e.g. why stable wormholes probably don't exist). Still might make it's own excellent sci-fi book if someone ran with the constrains of this, and it would technically be harder sci-fi than most.

</comment><comment><USER8> I don't see how time travel doesn't violate the law of conservation of energy or conservation of mass. That seems pretty fundamental to me, so it would require converting an extremely large amount of energy into the mass that is going back in time.

<comment><USER9> What if you can only send and receive information?

</comment></comment><comment><USER10> Theoretically yes, but what they didn't tell you is that all those particles travelling through will completely lose all their information and order how they belong together. So please dear sci-fi authors stop with these ridiculous plots.

</comment><comment><USER11> If I read that correctly, you are never able to travel back further than the creation of the wormhole.

<comment><USER3> Sounds like the movie Primer

</comment></comment><comment><USER12> The real question I have is how would you ever stabilize something as powerful as a black hole.

<comment><USER13> universe> ssh god@blackhole-42

universe@backhole-42> configure

universe@backhole-42> set stable MAX_VALUE

universe@backhole-42> commit

..changes successfully committed to blackhole-42

universe@backhole-42> exit

universe>

</comment></comment><comment><USER14> It seems we have laws of physics covering everything from Newtonian mechanics, relativity and quantum mechanics... Is there any law stating time travel must go one direction? Has it ever been proposed?

<comment><USER15> Second law of thermodynamics [https://en.wikipedia.org/wiki/Entropy_(arrow_of_time)](https://en.wikipedia.org/wiki/Entropy_\(arrow_of_time\))

<comment><USER12> > _The Second Law of Thermodynamics states that the state of entropy of the > entire universe, as an isolated system, will always increase over time_

My understanding (which is _very_ small) is that the multiverse theory takes care of not violating this law, since it's not an isolated system.

<comment><USER16> And....there is no evidence at all that there is another Universe other than ours. Once you have proven the existence of a multiverse we can then take theories that require it seriously. Until then it is pure fantasy.

</comment></comment></comment></comment><comment><USER17> > If this negative mass/energy matter exists

</comment><comment><USER18> Once

</comment><comment><USER19> Travelling backwards in time is not possible, it's obviously not possible, and it's a wonder that the idea gets given such credence in educated circles, apart from it being a nice thought and a diverting intellectual exercise.

<comment><USER20> Actually, time travel is real. My name is John Titor, from the year 2036. I'm looking for an old IBM 5100, does anyone here know where I can find one? The future of the world depends on it!</comment></comment>


Microsoft cuts 3,000 jobs in smartphone division, sales - <AUTHOR> http://arstechnica.com/business/2016/07/microsoft-2850-job-cuts-windows-phone-sales-nokia/ <comment><USER2> I hadn't noticed how disastrous Microsoft's acquisition of Nokia turned out to be. According to this article, along with the $7.1 billion purchase price, which has been written off entirely, 30,500 people have lost their jobs.

Hindsight is 20/20, of course, but it's hard to believe that Nokia would have done worse if it had remained independent.

<comment> T-A Nokia did remain independent. They just sold the mobile division to Microsoft, along with a time-limited license for their brand.

They are getting back into the tablet and phone market now: [http://gadgets.ndtv.com/mobiles/news/nokia-branded- android-s...](http://gadgets.ndtv.com/mobiles/news/nokia-branded-android- smartphones-tablets-to-launch-in-q4-2016-report-874229)</comment></comment>


When Cookies Lead to a DoS in PhpMyAdmin CVE-2014-9218 - <AUTHOR> http://www.behindthefirewalls.com/2014/12/when-cookies-lead-to-dos-in-phpmyadmin.html

<comment><USER2> While I agree this is a critical security flaw who in their right mind would expose phpadmin to the outside world? Is this something that is commonly done?</comment>


Release Early - <AUTHOR> http://www.prateekdayal.net/2009/05/16/why-you-are-not-gonna-release-early-and-release-often-and-why-you-should/

<comment><USER2> More content we don't need.

Has any one here not read a plethora of articles like this already?

</comment><comment><USER3> Hmm, while the point is good (and oft-repeated), this article is a little confusing in both its title and the way it phrases things...

The linked Mixergy extract is very good though.

</comment><comment><USER4> And often.</comment>


Why Hackathons? - <AUTHOR> http://blog.wylie.su/why-hackathons/

<comment><USER2> I agree. Properly organized hackathons (that aren't merely a front for recruiting people) are great fun if you like the vibe of working around other people with a major time constraint. It forces you to come up with some clever ideas.

That said, I tend to work on my own or in a pair at these events. It's great being around people but ensuring you get reasonable consensus in a larger team is hard work and ideally demands you know your team in advance.

P.S. I think tickets might all be gone now, but <http://leedshack.com/> is next weekend. British readers might want to keep it on their radar for future reference as the last one was awesome.

</comment><comment><USER3> I think this is a pretty good summary of what Hackathons are all about. Sometimes they are crappy and draining, but when they work out, they are absolutely awesome. Those awesome times more than make up for the bad ones (If you get the chance to have one).</comment>


Should we abolish time zones? (2019) - <AUTHOR> https://www.wired.co.uk/article/universal-time-zones <comment><USER2> No, but we should certainly abolish daylight savings time.</comment>


Alpha Compositing - <AUTHOR> https://ciechanow.ski/alpha-compositing/ <comment><USER2> > _While describing a pixel as a little square is frowned upon in a world of > signal processing, in some contexts it is a useful model that lets us > calculate an accurate coverage of a pixel by the vector geometry_

I wish people would try to calculate the coverage of some other reconstruction filter instead of just separate little squares. I'm not convinced it would be more expensive, and would hopefully give better results (less griddy artifacts, better spatial resolution), especially for images that will be rotated or resampled later.

If we assumed a radially symmetric kernel, then coverage would just be some monotonic function of the distance from the pixel center to the edge, and this function could be approximated using some low-degree polynomial and computed very quickly.

(Maybe this has been done?)

<comment><USER3> > If we assumed a radially symmetric kernel, then coverage would just be some > monotonic function of the distance from the pixel center to the edge

I don't think that's true. Consider a simple case where the shape is a square and you are sampling in such a way that the closest edge point is closer to a corner of the square than the filter width. Using a function of distance you will get the same result as when sampling far from the corner. But the coverage is different in the two cases.

<comment><USER2> I'm just talking about rendering one edge (infinite line) separating the plane into two regions.

If you want to deal with pixels near multiple edges, it needs to be more complicated.

</comment></comment></comment><comment><USER4> On that last note about alpha compositing I really wish there was a way to opt into correct alpha composting on the web. Colors deserve more love!

<comment> iso-8859-1 I imagined while reading the article that SVG must be implemented using these techniques. You imply it differs. How?

<comment><USER5> There is a "color-interpolation: linearRGB" option in SVG, which seems to be implemented by browsers. See [http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/](http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/) for a more detailed examination.

<comment> iso-8859-1 Well, that page doesn't render correctly in Firefox, so I wouldn't say it is implemented by "browsers".

</comment></comment></comment></comment><comment><USER6> Sadly no mention of gamma correction, which is where many implementations of alpha blending fail.

<comment><USER5> It is discussed briefly at the end, but I agree with you that it should have been given more prominence.

<comment><USER7> This is a pretty thorough article. Why would you focus so much on gamma correction? How would you expand it?

<comment><USER8> Because taking gamma correction into account when doing blend operations is pretty vital if you want good results.

<comment><USER5> Also because it's by far one of the most common things people get wrong, or could do better, when implementing alpha blending.

<comment> mark-r You can get 90% of the way to correct just by using square roots and squares. There's really no excuse.

</comment></comment></comment></comment></comment></comment><comment><USER9> Beautifully written and illustrated article. The live examples are perfect. Back when I was in university this is what we imagined the future of technical literature would look like.

</comment><comment><USER10> Really nice and thorough article.

</comment><comment><USER11> _One approach is to use four sample points which lets us represent four different levels of coverage: 0, 1⁄3, 2⁄3, and 1:_

Four samples actually gives you five levels depending on how many points are covered: 0, 1, 2, 3, 4. So these correspond to quarters, not thirds.

</comment><comment><USER12> nice. already giving me some ideas for my silly little python-and-bird-video experiments ([https://www.instagram.com/reductionist_earth_catalog/?hl=en](https://www.instagram.com/reductionist_earth_catalog/?hl=en)). I was using the built-in compositing in pillow (PIL fork), but maybe I should try rolling my own alpha compositing module using numpy.

<comment> mark-r The original PIL was pure junk when it came to doing things correctly. Pillow is better but I haven't tried to quantify it yet.</comment></comment>


Viral Video Shows the Extent of U.S. Wealth Inequality - <AUTHOR> http://mashable.com/2013/03/02/wealth-inequality/

<comment><USER2> Meh.. what is this "wealth"?

At a certain point, (unless you're just stupid), you don't buy "stuff" with your money. When you have > $100 million, I prefer to think that you instead have the capability to direct the flow of cash in the economy. Yes, some people buy yachts and other nonsense, but really, what are you going to do with that much money?

There's a chart somewhere out there on the internet detailing exactly what Bill Gate's money is going into. And it's interesting, because a lot of it is going into things that help people. Now consider, what if Microsoft never existed; where would this money be? It would mean the average person would have a little more probably. But Gates is directing it toward people that have the _least of all_ (among some university donations, etc.)

I've always told myself that if I somehow ever came across a lot of wealth, I wouldn't live any differently. I wouldn't own a car > $30,000. I wouldn't buy an extravagant house or a nice piano, because personally, I would feel guilty about having luxury items like this when other people have so little. I'm not judging people that do; I'm just saying that for me personally, it wouldn't work. So I would put my wealth into 1) disease research 2) education 3) 3rd world support. Maybe some other things; I'd have to think more about it.

And I'd hate someone to say "Oh, look at how rich that person is. It's not fair."

EDIT: Nothing's worse on HN than writing a long response and having the article jump from the 1st page to the 3rd. I may as well be writing to nobody.

<comment><USER3> I was gonna write a lengthy response to your comment, but then, I don't need to, a rich person already held a TED talk exactly why gross inequality is problematic: <http://www.youtube.com/watch?v=iIhOXCgSunc>

</comment></comment><comment><USER4> This is pretty frightening.

Banks are too big to fail and now too big to jail; it follows that the top 1% also has these attributes. Does that mean the American government is powerless to affect change?

What's more likely to win their vote? A pile of money, or lots of phone calls? I hope we figure something out before it's too late ... this trend is only going to get worse.

</comment><comment><USER5> Unless everyone has exactly the same amount, it is mathematically necessary that the top N% percent will have more than N% of the wealth. The same reasoning can be applied iteratively within each wealth group.

Most people who write about wealth distribution on blogs or popular political sites and forums, or make videos about it, don't seem to understand this, and so fail to start with a reasonable model of what a fair wealth distribution would be.

<comment><USER6> While this is mathematically true, I don't think it is necessary to acknowledge it in order to suggest/discuss a reasonable model for wealth distribution. I would even say that it is beside the point. The OP is trying to show that the order of magnitude of US wealth (or income) inequality is shocking. Moreover, most of us vastly underestimate the magnitude of US wealth inequality. And I would add as an example that many still believe in the American Dream, even if the US is one of the worst OECD countries when it comes to social mobility [1]. As George Carlin was saying, "You have to be asleep to believe it."

Back to the OP, when the top 1% has 24% of income (and 40% of wealth), that means there's a lot of luxury in the US which could instead be used to improve the life of some other less fortunate citizens. The economics rhetoric is clearly failing: the current wealth distribution is certainly not the most efficient distribution of resources if one is to include "quality of life" in the equation.

[1] [http://www.oecd.org/eco/growth/economicpolicyreformsgoingfor...](http://www.oecd.org/eco/growth/economicpolicyreformsgoingforgrowth2010.htm)

</comment></comment><comment><USER7> Two observations:

1\. Working hard doesn't entitle you to anything. Tired of politicians making this claim.

2\. Part of rise in inequality is powered by technology. I'm sure in 1970 you couldn't have created a billion dollar company with 12 people in 2 years (Instagram).

<comment><USER8> "Working hard doesn't entitle you to anything." -- well said. I am a software engineer, I always worked hard and I have a good income; but I'm by no means rich and most likely will never be, mostly because I've got no entrepreneurial genes. But that's alright, I think people who (besides the hard work) take high risks by creating new companies or even working their asses off in a startup that may or may not succeed, deserve an extra reward.

OTOH, the poor schmucks who work in the car wash a few blocks of my house, so I can have my car cleaned for $9 even in the winter with temperature below freezing? I would say they work much harder than me. And very likely they always did, they were already sweating over some soul-crushing job when they were teenagers (or even earlier), while at that age I had the privilege of being fully dedicated to my education. Not to mention always having a good and stable life -- food, healthcare, parents who had the means to care for me, etc.

Simple truth is that inequality of opportunities is huge. Another poster mentioned Bill Gates, well I don't take his merit away but Gates was the son of a wealthy attorney and a wealthier banker. Even Bill's entrepreneurship is something that can be attributed at least in part to the fact that he had a very good safety net to fall -- if he failed, he wouldn't exactly be screwed for a decade with debt.

</comment></comment><comment><USER9> How is this kind of data acquired? I suppose we don't know precisely who the 1% guy is, right?

</comment><comment><USER10> This is pretty disingenuous. The creator of this video would have you believe that the wealthy 1% are like Scrooge McDuck sitting on vaults full of cash amounting to tens of trillions of dollars, and this is why some people are poor.

</comment><comment><USER11> So, I wonder what a tax policy would actually look like that would revert us to "what we think it is". What would the marginal brackets be? Seems like it would have to require a heck of an estate tax, too.

</comment><comment><USER12> I'd like to see a wealth data compared to data on how people spent their free time over their lifetimes.

The only thing to get upset about is wasted potential.

<comment><USER9> You reminded me of Bill Gates, who said that in his youth, he never took a day off, ever.

</comment></comment><comment><USER13> The historgram seemingly fits Zipf's law. I am not shocked. That is a law after all.</comment>


"Hand of Thief" Trojan Targets Linux - <AUTHOR> https://blogs.rsa.com/thieves-reaching-for-linux-hand-of-thief-trojan-targets-linux-inth3wild/ <comment><USER2> Also written up on Arstechnica ( [http://arstechnica.com/security/2013/08/hand-of-thief- bankin...](http://arstechnica.com/security/2013/08/hand-of-thief-banking- trojan-doesnt-do-windows-but-it-does-linux/) )

It is not a real remote exploit due to any flaw in Linux, rather it is something the purveyors trick people into installing via "social engineering".

<comment><USER3> Don't copy and paste commands into your shell, kids.

<comment><USER4> Even if they look safe: [http://thejh.net/misc/website-terminal-copy- paste](http://thejh.net/misc/website-terminal-copy-paste)

<comment><USER5> Indeed. This is one of the reasons I use the SELinux sandbox to run my browser: there are a lot of ways that a browser could become a vulnerability. I would like to think I would always remember not to copy/paste from a website into my terminal, but the truth is that I could easily forget -- if I were in a hurry, if I knew the guy who made the website (but did not stop to think that someone might have hacked into the server), etc. Unfortunately it is hard to advise that _everyone_ do this; the sandbox is very restrictive and basically incompatible with how most people use their computers.

<comment><USER6> Do you have any write-ups on how one would accomplish this SELinux sandbox for your browser? Thanks!

<comment><USER5> [http://danwalsh.livejournal.com/31146.html](http://danwalsh.livejournal.com/31146.html)

One very simple way to get a sandboxed browser is to run this command (my irony meter is going off the charts here):

sandbox -X -t sandbox_web_t firefox

However, that will prevent any persistence between sessions, so you probably want to do something more like this:

sandbox -X -H /path/to/some/directory -t sandbox_web_t firefox

My recommendation is that you read the man pages and experiment a bit.

<comment><USER7> _my irony meter is going off the charts here_

Nothing wrong with showing commands and examples to be used. It's the cut-and- paste aspect that's an issue.

My first action was to search through my package repos (Debian) to see if that sandbox command is known to my packaging system (it's not, hrm...).

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Does this mean that Linux has arrived as a desktop that's worth exploiting?

<comment><AUTHOR> That was my takeaway.

</comment></comment><comment><USER9> The article is missing the MD5 hashes of the malware sample. There is an old adage from malware reverser: "MD5 or it didn't happen".

</comment><comment><USER10> This website has got a wrong and expired SSL certificates.

<comment><USER11> Yes... accept it so we can hack you next time more easily ;))

</comment></comment><comment><USER12> Working link: [http://www.zdnet.com/linux-desktop-trojan-hand-of-thief- stea...](http://www.zdnet.com/linux-desktop-trojan-hand-of-thief-steals- in-7000019175/)

</comment><comment><USER13> Given the high price relative to the number of consumers that might be attacked with this software, I'd bet that it will mostly be purchased by people who want to do spear fishing.

</comment><comment><USER14> Anyone know what technique this package uses to grab information from forms?

LD_PRELOAD? ptrace?

I googled but only found ways of doing this that are Win32-specific.</comment>


Spaceteam is now a chaotic and cooperative card game (currently on Kickstarter) - <AUTHOR> https://www.kickstarter.com/projects/mathewsisson/spaceteam-0 <comment><AUTHOR> Matt one of the creators of the card game here! Happy to answer any questions about how we translated the mobile app into a tabletop game.

<comment><USER2> Spaceteam has to be one of my favorite multiplayer/in person mobile games but one of the things that makes it fun is the app itself creates the chaos and time crunch. Do you see the card game being able to maintain that same level of excitement and chaos?

<comment><AUTHOR> For sure! That was our biggest design challenge with converting it over. We have a sand timer that helps, but that time crunch feeling is something that's generated by the players oddly enough.

In the card game, you're frantically trying to work through malfunctions that are repaired by different tools that your teammates have around the table. When, and only when, you get through a chunk of your pile, you were begin to reveal the System Go cards that restart your Spaceship. We also bring in physical activities such as people needing to change seats or tools switching hands to keep the chaos alive throughout the 5 minutes.</comment></comment></comment>


The DevOps Handbook - <AUTHOR> https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002 <comment><AUTHOR> Gene Kim is also one of the authors of "The Phoenix Project"[0] which is a highly recommended read.

[0] [https://www.amazon.com/Phoenix-Project-DevOps-Helping- Busine...](https://www.amazon.com/Phoenix-Project-DevOps-Helping- Business/dp/0988262509)

</comment><comment><USER2> I wish it was possible to take the DORA DevOps X-ray Assessmnent for free, before deciding on whether to buy or not to buy the book.</comment>


How to not get fooled by a social media expert con artist  - <AUTHOR> http://www.24100.net/2011/05/how-to-not-get-fooled-by-a-social-media-expert-con-artist/ With the explosion of so called Social Media Experts, I had to get this out. What do you think? <comment><AUTHOR> What do you guys think?</comment>


Maya – Python Datetimes for Humans - <AUTHOR> https://www.kennethreitz.org/essays/introducing-maya-datetimes-for-humans <comment><USER2> Awesome! Timekeeping is hard and I'm glad we now have one more tool do deal with it.

One thing that is bothering me is that when you ask for `maya.when('tomorrow')`, or give only a date, you get back a timestamp with millisecond precision, representing 00:00 of that day. I understand this simplifies the implementation, but shouldn't `tomorrow` be a _range_ , from 00:00 to 23:59?

Treating imprecise dates as ranges would allow for stuff like

        # Did this event happen "yesterday" according to the US/Eastern time zone?
        timestamp in maya.when('yesterday', to_timezone='US/Eastern')

        # Get me all events that happened last Friday (UTC)
        [event for event in events if event.time in maya.when('2016-12-16')]

Maybe I'm being naive, and there's a reason why this won't work, but this seems the way most humans deal with time.

PS: it failed to install on Windows, so I opened an issue at [https://github.com/kennethreitz/maya/issues/10](https://github.com/kennethreitz/maya/issues/10)

<comment><USER3> How would you serialize that range to, for example, ISO8601?

<comment><USER4> From wiki: ISO8601 has four ways to express a time interval:

1\. Start and end, such as "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z".

2\. Start and duration, such as "2007-03-01T13:00:00Z/P1Y2M10DT2H30M"

3\. Duration and end, such as "P1Y2M10DT2H30M/2008-05-11T15:30:00Z"

4\. Duration only, such as "P1Y2M10DT2H30M", with additional context information

[http://en.wikipedia.org/wiki/ISO_8601#Time_intervals](http://en.wikipedia.org/wiki/ISO_8601#Time_intervals)

</comment></comment></comment><comment><USER5> I wish Kenneth would have contributed to an existed project for once.

Arrow and pendulum (my current favorite) have a very decent API. The later one is especially well tested for the numerous corner cases of date handling, which I doubt Kenneth got right on first try.

For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives. But for date time, alternative exists and they are good. Do not split the open source effort, join forces!

<comment><USER6> Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network effects that come from having more people involved in the project. I don't think that applies here.

This library is not going to divert much (any?) effort that could have improved other date-time libraries.

<comment><USER5> If you contribute to any open source project, you quickly learn code is only a small (yet important) part of the effort.

Other stuff that are splitted:

\- attention;

\- visibility;

\- pull requests;

\- documentation edits;

\- bug reports;

\- installs (and hence testing on the field);

\- compatibility layers;

\- compatible tooling;

\- 3rd party tutorials, snippets and examples;

\- help from integrators;

Now if you don't have any very good alternatives, it's good : you want to steal that from them. But when you DO have good existing projects, then those are the bread and butter of their success.

Now I know it's way harder to contribute to something than roll you own. I know that's it's also more fun to roll your own. And there is the ego at play as well.

I understand all that, and I respect Kenneth as a professional. But I don't think it's a good call on his part here.

It is espacially true for him, because he now have such a good rep in the Python community that everything he does get under the spotlight.

<comment><USER6> Have a look at the code [1]. There's maybe 20 lines of actual logic in there.

Even taking all of what you mentioned into account, it's still not more than a single afternoon.

I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that.

[1]: [https://github.com/kennethreitz/maya/blob/master/maya.py](https://github.com/kennethreitz/maya/blob/master/maya.py)

</comment></comment></comment></comment><comment><USER7> I think its fascinating that the community has no consensus about a datetime library.

A lot of Python is really solved. We don't argue about using requests (a not- coincidental example). If you're using Python, and you need to deal with http, you use requests. Everyone knows this.

There are basically 3 platforms for web frameworks. Flask, Pyramid, and Django. Maybe we're a little more dissolute than C# or Ruby folks, but that's pretty impressive considering how much we Python people like to roll our own.

The fact that there is real disagreement about this among ourselves about this particular issue says to me that this is more about the difficulty of the problem than it is anything else.

<comment><USER8> Related: the datetime library in pretty much every language is terrible. The only one I've ever used that I remember not actively hating was MomentJS.

Python's history of time types was terrible, as well. Particularly the era when we just used tuples of length 8 or 9 that weren't timezone aware.

<comment><USER9> > The only one I've ever used that I remember not actively hating was > MomentJS.

Boy do we disagree. Between the mutable API, the fuzzy parsing, the lack of tz support and the yet-another-reinvention of date/time formatting DSL[0] moment was one of those things I'd rather have not had in my life.

[0] which, to add insult to injury, is really similar to but not quite compatible with the LDML's

<comment><USER10> I've used timezones with momentjs. [http://momentjs.com/timezone/](http://momentjs.com/timezone/) Its great. The parsing also has a strict mode [http://momentjs.com/docs/#/parsing/string- format/](http://momentjs.com/docs/#/parsing/string-format/)

When did you last use it? I love working with momentjs.

<comment><USER9> > I've used timezones with momentjs. > [http://momentjs.com/timezone/](http://momentjs.com/timezone/) Its great. > The parsing also has a strict mode > [http://momentjs.com/docs/#/parsing/string- > format/](http://momentjs.com/docs/#/parsing/string-format/)

Yes, relatively recent options or completely separate projects allow doing these things. Do you know what happens to options when the default behaviour looks like it works? They don't get used, and the original garbage remains.

> I love working with momentjs.

And as I wrote earlier, boy do we disagree.

</comment></comment></comment></comment></comment><comment><USER11> What's up buddy?

My only real question:

> rand_day = maya.when('2011-02-07', timezone='US/Eastern')

This returning an object representing a DateTime on the 6th (in UTC time) strikes me as perhaps "not for humans."

If I just see that line casually, I think I expect to get a Date and for it to be the 7th.

It looks like, in order to get this (arguably expected) object, I need to take the resulting MayaDT epoch and run its `datetime` method, passing naive=True?

And I also see that _tz can only ever be pytz.timezone('UTC') - is this the result of some belief that timezones are illusions or something? :-)

For a while, I have kinda thought that timezones foment a confused mental model of time and teamwork. I prefer to think in terms of the astronomy - it's not actually a _different time_ anywhere else, it's just that the sun is at a different position relative to the rest of the earth (and thus, ones faraway teammates and loved ones).

Anyway, thanks for yet another set of interesting ideas. Hope you are well.

<comment><USER12> It's worth thinking of it the same as strings. Strings can have several encodings, e.g. ASCII, UTF-8 and a hundred others. These are external representation. You don't want to parse the string every time you have to deal with it, so you parse it and store it using (ideally) a single internal representation (e.g. UCS-2, UCS-4). Then, when you need to pass the string to something else, you encode again.

Same with dates. Instead of trying to deal with and store all possible representations (format, timezones, etc), you convert all dates to a single representation (hence UTC). When you need to output the date, encode it into whatever format and timezone you need.

It's much cleaner this way, because there's less chance you'll mix up representations. So the "for humans" part is more "for developers, which are also humans but like to pretend they aren't and never make mistakes".

</comment></comment><comment><USER13> I wonder if the naming isn't a bit unfortunate, seeing that Maya is one of the major 3d packages out there and googling for Maya and Python will almost always lead there (also, not sure whether Autodesk might object...)

<comment><USER14> Yep. Picking cute short brand names for libraries as though they were startups clutters up the namespace of programmer's conversational language causing ambiguity and obfuscation. It would make life easier if we adopted an informal naming convention for small libraries e.g. <lang><brand><purpose>. Lang is useful when libraries get ported so you get e.g. PyMayaTime, GoMayaTime etc. Still sounds cute but you know what its for when you pick up someone else's code and its easy to google.

<comment><USER15> Picking names which collide with stuff seems to be the standard these days. Don't get me started on Google(Chrome, Go)

</comment></comment></comment><comment><USER16> Not to undermine its merit, but most of the dirty work and heavy lifting is done by its dependencies:

[https://github.com/kennethreitz/maya/blob/d57a78c6bc6b5295f7...](https://github.com/kennethreitz/maya/blob/d57a78c6bc6b5295f7d7207be0ee7cf0d62f063f/setup.py#L14-L20)

And i18n support in humanize is a bit lacking, as it only translates to French, Korean and Russian. Given that most of the translations needed to render human dates can be found in the CLDR database, maintaining their own looks like a bit of a wasted effort.

Reference:

[http://cldr.unicode.org/](http://cldr.unicode.org/)

<comment><USER9> > Given that most of the translations needed to render human dates can be > found in the CLDR database, maintaining their own looks like a bit of a > wasted effort.

You still need to parse the CLDR (the formats are pretty wonky) and provide APIs for its functions. Of course that's what Babel ([http://babel.pocoo.org](http://babel.pocoo.org)) does.

<comment><USER17> and here I thought babel was for es2015

</comment></comment></comment><comment><USER18> Kenneth Reitz is a testament to how important good interfaces are in the developer community. There are literally 0 interesting things in the code (all dependency driven, [https://git.io/v15i3](https://git.io/v15i3)). It does have a nice interface and because of this it will probably become one of the more popular python datetime libs.

<comment><USER19> Arguably bringing multiple dependencies under one roof, with a nice, human- readable interface, is exactly what the value is here. This SO answer from Pandas lead Wes Mckinney says it better than anything I could comment. Python datetime/timestamp management: "Welcome to Hell"

[http://stackoverflow.com/questions/13703720/converting- betwe...](http://stackoverflow.com/questions/13703720/converting-between- datetime-timestamp-and-datetime64)

I run batch and real time financial feeds into Python from multiple sources, inevitably from different programming language paradigms, and with different time/date/timezone conventions, and then I allow user interaction with it in their own lingo for dates and times, and my experience is that it is indeed hell consolidating all this into a common tongue. The "slang time" idea suggest to me that this library understands the need for flexibility and malleability in this very disjointed and often frustrating part of the Python ecosystem.

<comment><USER20> I think there are two separate issues here.

One thing is that some libraries bring their own not-really-different-just- different-enough-to-break-things date/time types to the table. That can be worked out over time, not that big of a problem, just inconvenient.

The other is that I've grown to think that the abstraction commonly used, seeing date/time as something like (year, month, day, hour, minute, second, subsecond, timezone) is in itself not really suitable, because the derived interfaces (like accessing and modifying days, months etc. separately) mean that most code working with these will inevitably be bug-ridden.

The root cause for this is imho that date and time are extremely complicated and it's usually unclear what the correct behaviour would be in any of the many, many edge cases.

Some examples:

1.) One week after `this` date. Does this mean, add seven days? What about leap days? Should the result be the same weekday, just in the next week instead?

2.) Start and end time of a process should be recorded. The process starts and finished. All good. The duration of the process is -1 hour and 5 minutes. Should instead a start timestamp be recorded and a monotonic duration? Or perhaps we should rather note the begin of a monotonic period and record an end timestamp, deriving the start timestamp? Which is correct?

3.) One ^W two words: _recurrence rules_

4.) DST

5.) Combining 3.) and 4.)!

 _dom 's rule of thumb_: if code does addition or substraction with some measure of time, it's probably wrong.

<comment><USER21> Regarding recurrence rules specifically, I worked in the financial services industry and bonds and derivatives obviously recur (usually monthly) for decades.

Not only do you need to specify the precise dates of recurrences, but you also need to map time intervals to fractions of a year (e.g. if I owe you $1mm a year, is 'one month' equal to 1/12 of a year, or do I count the actual numer of days in between? What about leap days, etc.). Getting it wrong even slightly means you get all the cashflows wrong.

Welcome to the joy of 'day count conventions' [1] and 'date rolling' [2].

[1] [https://en.wikipedia.org/wiki/Day_count_convention](https://en.wikipedia.org/wiki/Day_count_convention) [2] [https://en.wikipedia.org/wiki/Date_rolling](https://en.wikipedia.org/wiki/Date_rolling)

Funny thing is these have _all_ probably be reimplemented from scratch at every single bank.

<comment><USER19> I've personally re-implemented bond daycount for multiple markets several times at different shops. Maybe quantlib has this? Have never been allowed to use it.

<comment><USER21> Quantlib has a relatively small set implemented:

[https://github.com/lballabio/QuantLib/tree/master/ql/time/da...](https://github.com/lballabio/QuantLib/tree/master/ql/time/daycounters)

</comment></comment></comment></comment></comment></comment><comment><USER22> How does it differ from Arrow which was made several years ago? [1]

[1] [http://crsmithdev.com/arrow/](http://crsmithdev.com/arrow/)

<comment><USER23> That would be nice to know. Arrow still seems active, and has been consistently so over the last 3 years.

I have a bit of doubt about a time library that defaults to UTC but uses human phrases like "tomorrow". Who thinks about UTC tomorrow?

<comment><AUTHOR> that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)

<comment><USER24> That's great, but why this then:

        >>> tomorrow = maya.when('tomorrow')
        <MayaDT epoch=1481919067.23>
        >>> tomorrow.slang_date()
        'tomorrow'
        >>> tomorrow.slang_time()
        '23 hours from now'

Huh? Given that we never specified timezone, I would expect 24h (unless DST change happens).

This is actually my biggest gripe with date+time libs. Imho API should always be explicit in what its default TZ is.

EDIT: still, appreciate what you are doing. Requests rule, and there are many other areas (including datetime) that need libs with better APIs. Thumbs up!

<comment><USER25> Why on earth is 'tomorrow' just +24 (local) hours. I'd expect it to be the next calendar date.

<comment><USER26> I suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.

<comment><USER27> Conversely, +24 hours may fall on the same calendar date or two calendar days on from now.

Really, "tomorrow" should be the interval from the beginning of the next calendar date to the end.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> I have found that no matter what language/platform I use, the one thing that is always supported is UNIX timestamp. That makes date+time operations much easier:

      1) Whenever dealing with users, use local tz.
      2) Always save and manipulate in utc.

<comment><USER9> Except (2) doesn't necessarily work when events are _local_ and you factor in timezone variations (both DST and actual TZ changes). There are classes of events where you're much better off with zoned local dates e.g. local meetings.

Example: in early 2011, Samoa announced that on December 29th at midnight _local_ they would switch their timezone offset from -11 to +13. Before that announcement (or at least before your timezone database has been updated), store as UTC a meeting in local Samoa time, and the user will miss their meeting by a day.

Of course storing a meeting on December 30th local would also have been fraught as there is no December 30th 2011 in Pacific/Apia but that is a _common occurrence_ historically due to the unsynchronised julian/gregorian switches e.g. none of the dates between February 16th and February 28th 1923 (included) exist in Greece, and the US doesn't have a 9/11 in 1752.

<comment><USER28> I think the recommendation still holds.

You want a meeting at 1100 local time.

Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant)

Samoa changes the rules.

The calendar doesn't change.

This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

<comment><USER29> Classic counter example: storing business hours. If the store/exchange opens at 8:00AM every weekday in Somethingania/Foocity, you want to store 8:00 and the name/reference of the timezone. Because the store/exchange will still open at 8:00AM local time, even across DST, government-mandated timezone changes etc (largely, I'm sure there are exceptions but for stock exchanges there definitely aren't).

School times, times for religious services, lots of times are relative to local time, which itself is subject to change against UTC (sometimes predictable, sometimes not, the government gets to update the timezone and the DST scheme arbitrarily). So only ever storing UTC and using local time purely for display isn't a sustainable one-size-fits-all option.

</comment></comment></comment></comment><comment><USER20> > Datetimes are a headache to deal with in Python, especially when dealing > with timezones, especially when dealing with different machines with > different locales.

Anything with date/time calculations is always a pain, probably doesn't really have much to do with the library/language itself, but that the abstraction level that's used (and typically used in other libraries) means that the complexities of calendar and time systems are sprinkled all over application code.

I do have to notice here that always using UTC is _not_ always the right thing to do. For example, evaluating rrules in UTC is rather error-prone (DST).

<comment><USER30> If you're mixing UTC and DST you are doing something wrong.

<comment><USER31> I think what dom0 means is a situation like the following. Say you want to schedule, on a calendar, an event that happens daily at 2PM in your local timezone, say America/New_York. If you record that even as happening at 2200 UTC each day, when DST rolls around, it'll shift to 1PM or 3PM in the local timezone. This is not what the user wants.

Here, despite storing everything in UTC and attempting to apply DST as late as possible as if it were a "display issue" — normally the right thing — here results in the wrong outcome.

<comment><USER30> In your example what I said is still true.

The user didn't want a precise coordinated time (DST is not a factor for storage/recall); the user wanted a fuzzy reference to local time (DST is a factor for evaluation).

</comment></comment></comment></comment><comment><USER32> I like Kenneth's work, but "I wrote a new datetime library" is a cliche now. We have datetime, dateutil, pytz, babel, arrow, pendulum, delorean, a bunch of lesser known stuff, and now this. I have yet to see the need for anything but the first four.

<comment><USER33> Seems to be a case of "Python Web Framework"-itis: it's relatively simple to hash up something from scratch that covers one's particular use-case (in this case, it seems, a slightly smarter parser), but it's actually hard to properly cover all use-cases.

This is what happened with Python web frameworks, a scene which was heavily fragmented before Django and Flask basically solidified the two main communities of users ("I need everything and the kitchen sink" / "I need the bare minimum to get going"). The same happened with urllib2/urllib3/httplib/ etc before Requests appeared.

Nobody seems to have pulled this trick for datetime libraries yet, so here's a new contestant.

</comment></comment><comment><USER34> My first commit to ago.py was 'Fri Jun 29 19:25:55 2012'.

        >>> import ago
        >>> import dateutil
        >>> ago.human(dateutil.parser.parse('Fri Jun 29 19:25:55 2012'))
        '4 years, 172 days ago'

     The current implementation is 66 lines of code including docstrings:

* [https://bitbucket.org/russellballestrini/ago/src/tip/ago.py](https://bitbucket.org/russellballestrini/ago/src/tip/ago.py)

* [https://pypi.python.org/pypi/ago](https://pypi.python.org/pypi/ago)

</comment><comment><USER35> I'm competent with strptime(), but this looks really nice:

        # Automatically parse datetime strings and generate naive datetimes.
        >>> scraped = '2016-12-16 18:23:45.423992+00:00'
        >>> maya.parse(scraped).datetime(to_timezone='US/Eastern', naive=True)
        datetime.datetime(2016, 12, 16, 13, 23, 45, 423992)

I'm happy not to have to write formatting arguments to strptime() anymore. Do the other datetime libraries have similar parsing functions?

<comment><USER36> Maya actually uses the dateutil.parser.parse function from dateutils under the hood, which as far as I remember is the most comprehensive such function among the typical python datetime libs.

<comment><USER35> Wow, I've been using datetime for years, without ever noticing the dateutil library. I'll use this from now on.

</comment></comment></comment><comment><USER37> I suppose this beats breaking out time delta, but I think it'll be hard for me to see an actual use in my projects that I couldn't accomplish with maybe just a couple extra lines

<comment><AUTHOR> you'd be surprised, the amount of headache-inducing code that timezones can cause, especially when dealing with servers with different locales than your development machine when doing timezone algebra.

This API avoids that problem entirely.

<comment><USER38> It does not: timezone (TZ) definitions are politicial, inaccurate, and stupid and non versioned.

The problem with TZ is TZ in its core definition.

1) they always change: if you have not updated your TZ since 3 months they are probably inaccurate

2) your TZ definition maybe accurate but they may not have been applied for real in the concerned zone

3) you can have different local time for the same longitude

4) you can have different days on the same longitude ...

5) TZ are not versioned, if the TZ changed between 2 records you may have made, you have inaccurate intervals stored. We do NOT have an API to take TZ change over time in consideration.

6) CEST/DST is breaking the axiom that time is a growing monotonic function

References 8.5.3 TZ in postgresql man [https://www.postgresql.org/docs/9.2/static/datatype- datetime...](https://www.postgresql.org/docs/9.2/static/datatype- datetime.html)

Computerphile what's wrong with timezones [https://www.youtube.com/watch?v=-5wpm- gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

<comment><USER39> The TZ database has versions and you could at least in theory expose that at a higher level in libraries.

<comment><USER40> Pretty sure pytz will hand you the appropriate timezone for a given date. There aren't version numbers after all but it can do the right thing based on when you say it is.

There is some weird behaviour due to this when trying to get a timezone without an associated date as it doesn't default to now.

Then again you probably have all sorts of DST bugs if you have places in your code that do that.

<comment><USER41> Pytz handles a certain class of funkiness in TZ changes, but not the one mentioned here. Consider, a user in footopia enters a datetime 3 months from now which is saved in UTC in your database. Then footopia changes their TZ definition. The only way you could get this right is if you also know when the datetime in the database was created. You would need to tell your datetime library the datetime and _when it was created_, and pytz doesn't do that (I don't know any that do, actually).

<comment><USER12> You'll never get this right, even if you had all of this info, because as mjevans points out[0] to make it work you need to know:

> P) The event is at a precise internationally recognized moment (better for > co-ordination globally).

> R) The event is in local time (like a lunch date) and expected to remain > colloquially fixed.

In the case you mention, it's somewhat arguable that the burden of changing the colloquially fixed dates (R) falls on the citizens of footopia, in the same way as changing the time of a purely mechanical clock also would. caveat emptor.

[0] [https://news.ycombinator.com/item?id=13206671](https://news.ycombinator.com/item?id=13206671)

</comment></comment></comment></comment></comment></comment></comment><comment><USER42> This is designed for programmers of user facing applications. For science and engineering, it does not address the problems, eg lack of leap seconds.

<comment><USER9> > For science and engineering, it does not address the problems, eg lack of > leap seconds.

What do you mean by "lack of leap seconds"? A non-unix-timestamp-based time library?

<comment><USER42> When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. You could use time_t underneath, if that's what you really wanted to do.

As my co-worker once put it, "time is a four letter word."

At the very least, there is a need for showing the occasional 61st second of a minute, and adding a time and timedelta where leap seconds is taken into account.

<comment><USER9> > When the mapping between a time_t and a "human readable format" (hours, > minutes, seconds, etc) takes into account extra leap seconds.

I still don't understand what you mean.

> You could use time_t underneath, if that's what you really wanted to do.

Well you've got unix timestamp (UTC) which "skips" leap seconds but as a result is very easy to map to "human time", or you've got TAI[0] which includes leap seconds but doesn't allow dates in the future since you don't know where and when new leap seconds will be added long in advance, and now you need regular updates/permanent connectivity so you can remap TAI onto human time. _And_ you need an NTP replacement, though I guess having a GPS unit in everything would do.

[0] and GPS time which is just TAI + 19s

<comment><USER31> What I believe he's trying to say is that sometimes, you need a library capable of the following:

        2016-12-31T23:59:30Z + 60s == 2017-01-01T23:59:29Z

(The above is a true statement, due to the presence of a leap second in the duration.)

Python does not do this:

      In [5]: datetime.datetime(2016, 12, 31, 23, 59, 30, tzinfo=pytz.UTC) + datetime.timedelta(seconds=60)
      Out[5]: datetime.datetime(2017, 1, 1, 0, 0, 30, tzinfo=<UTC>)

(Nor does Arrow. Maya doesn't really seem to support arithmetic on a MayaDT short of converting to a datetime, so in that regard, it behaves like Python.) The above output is not terribly surprising, as Python and a lot of software tend to follow Unix/POSIX time. Whether it is "right" depends.

You also mix up the various timescales:

> _Well you 've got unix timestamp (UTC) which "skips" leap seconds_

Unix/POSIX time might not skip leap seconds; some will repeat a second as the leap second occurs. (I.e., while UTC counts 23:59:59, 23:59:60, 00:00:00, POSIX will count 23:59:59, 23:59:59, 00:00:00.) Linux falls into this latter case, I believe, during which time adjtimex() will return TIME_OOP.

However, Unix/POSIX time is not UTC. UTC never "skips" leap seconds, as leap seconds are an inherent property of UTC.

> _or you 've got TAI which includes leap seconds_

TAI does not include leap seconds[1]:

> _the name International Atomic Time (TAI) was assigned to a time scale based > on SI seconds with no leap seconds._

> _TAI is exactly 36 seconds ahead of UTC. The 36 seconds results from the > initial difference of 10 seconds at the start of 1972, plus 26 leap seconds > in UTC since 1972._

UTC: has leap seconds as a property of how it works

TAI: does not include leap seconds

POSIX/Unix time: an integer that can be mapped to UTC except during leap seconds, where it becomes ugly (unless you know if TIME_OOP was set, in which case it can still be mapped to UTC).

> _but [TAI] doesn 't allow dates in the future since you don't know where and > when new leap seconds will be added long in advance, and now you need > regular updates/permanent connectivity so you can remap TAI onto human time_

With the above, it should be obvious that this is a property of UTC, not TAI. TAI timestamps in the future should be stable/usablable without surprises. UTC's might not be due to leap seconds.

[1]: [https://en.wikipedia.org/wiki/International_Atomic_Time](https://en.wikipedia.org/wiki/International_Atomic_Time)

<comment><USER9> > You also mix up the various timescales:

No, but I think we're interpreting the word "skipping" differently which leads to confusion. To me, in TAI, a "leap second" is nothing special and included in the normal time stream, in UTC the leap second is removed from the normal time stream and tacked on as a special case on some specific days, hence skipping it, hence UTC running late compared to TAI: UTC has "removed" 36 seconds from the timestream compared to UTC.

> Unix/POSIX time might not skip leap seconds

UNIX/POSIX can only ignore leap seconds, how it does so doesn't matter, because it's defined as constant-length days, the timestamp is 86400 _days since epoch + seconds since midnight. The day after a leap second, that leap second has "disappeared" from the timestamp sequence.

> However, Unix/POSIX time is not UTC.

Unix time is specifically defined as UTC (at least after January 1st 1972 since that's when UTC was defined, pre-72 it's ambiguous), though not true since it can't _represent* leap seconds. Outside of the extent of leap seconds, UNIX time tracks UTC exactly.

> as leap seconds are an inherent property of UTC.

They're an inherent property of UTC in that it removes them from normal time treatment.

> TAI does not include leap seconds[1]:

It includes them in the sense that it treats them as perfectly normal seconds without anything special about them.

> With the above, it should be obvious that this is a property of UTC, not > TAI.

The paragraph you're quoting here (and my entire comment really) is talking about how these systems _map to human time_ aka year/month/day/hour/minutes/seconds. Leap seconds were introduced specifically for that purpose, and UTC (and unix timestamps) are thus trivially mappable _by definition_.

Because it does not, TAI can't be mapped to human time without leap seconds definition AKA May 7th, 2078 at 17:54:33 is known in UTC, but not known in TAI, because we don't know how many leap seconds will be introduced in the next 61 years and that's necessary to map TAI to and from human time.

</comment></comment></comment></comment></comment></comment><comment><USER43> But does it get DST correct. I haven't found any python time libraries that do.

<comment><USER44> You can take a look at pendulum: [https://github.com/sdispater/pendulum](https://github.com/sdispater/pendulum)

A lot of effort has been put into getting DST right so I hope it will be what you are looking for.

Disclaimer: I am the author of Pendulum :-)

</comment></comment><comment><USER45> Bikeshedding. The Python "datetime" module does almost all of this. (Although I did try to get ISO8660 parsing put in, after finding eight libraries for it, all of which were broken in some way.)

</comment><comment><USER46> People are asking why this is needed compared to Arrow and a few other libraries. Personally I was never happy using the python time libraries, it always felt like my use cases were slightly different then the library, and I always found myself getting frustrated over little things here and there. I think there are a LOT of use cases for time in python applications and there is plenty of room for small libraries to satisfy these conditions, versus one monolithic time library that attempts to solve all.

</comment><comment><USER47> I understand the link with the maya believes but for a "digital" feature, this sound a lot like an Autodesk product... That said, nice API!

</comment><comment><USER48>
        <MayaDT epoch=1481850660.9>

not the most human readable is it?

I guess it would help with like, "X happened before Y" situations, but I don't think I'd trust my eyes for that!

I think I would of preferred the "this happened in X month" case instead, I find it easier to trust my eyes for that, instead of trying to look for differing digits!

\- - -

UTC default is a godsend though

<comment><USER49> Fortunately it is really easy to print it in other formats. Which is certainly not the case for the standard datetime library.

</comment></comment><comment><USER50> [offtopic] I do not like the "for humans" thing. What could it be for instead? for kangaroos or giraffes?

<comment><USER51> Popo: An Artisinal Handcrafted Curated Simple-yet-Powerful Library (for Waterfowl). By L'Wren Scott.

</comment></comment><comment><USER52> Uh, Arrow? I'm not a big fan of it, really, as I've seen it to break silently on some edge cases API is not totally awesome, but this one doesn't seem to be any better. Still not sure if I should use this or that or write one of my own.

</comment><comment><USER53> Hopefully we will have a "API for Humans" for each of the standard library modules.

</comment><comment><USER54> _The link to its github was posted on HN when it was brand new, and I left a comment [6], which I 'm reproducing here -- since most of my points still apply._

(...) take my very early comments with a grain of salt -- they refer to the progress as of this commit [1].

I love Requests -- its API design is fantastic, and manages to distill down most of a complex problem domain to a clean, dare-I-say, elegant API. So I can eagerly anticipate this design applied to datetimes. But the progress being shown so far is definitely not it.

 _> >> tomorrow = maya.when('tomorrow')_

 _< MayaDT epoch=1481919067.23>_

Why is "tomorrow" a precise-to-centisecond, infinitesimally small point on a giant cosmic timeline? I'm reasonably sure it's an abstract concept that describes the calendar day that starts after the current calendar day ends.

At least, Pendulum normalizes tomorrow() and its ilk to represent midnight on the given day [2], while Delorean's natural language methods [3] like next_day() advance the day while leaving the time-of-day unchanged, but the method name makes this fairly clear.

Even Arrow, which is heavily inspired by Moment.js to the point of conflating every single datetime idea into the same class, opts for mutators that are still more clear [4].

 _> Timezones fit in here somewhere..._

Yeah, this needs more work.

Java 8 / Threeten, and its predecessor Joda-Time took the approach of clearly modeling each and every concept that humans actually use to describe time; even if you take issue with their API, the designers have clearly done their homework, and their data model is solid.

Formats like TOML wrestled with datetimes and realized [5] that datetimes aren't just woefully underspecified in most other specs and APIs, but that they're frequently mis-modeled, so they adopted large portions of Threeten's data model. Cases like this should merit strong consideration from anyone trying to propose new datetime APIs today.

[1] [https://github.com/kennethreitz/maya/commit/ecd0166ba215c1a5...](https://github.com/kennethreitz/maya/commit/ecd0166ba215c1a5..). [2] [https://pendulum.eustace.io/docs/#instantiation](https://pendulum.eustace.io/docs/#instantiation) [3] [http://delorean.readthedocs.io/en/latest/quickstart.html#nat...](http://delorean.readthedocs.io/en/latest/quickstart.html#nat..). [4] [http://crsmithdev.com/arrow/#replace- shift](http://crsmithdev.com/arrow/#replace-shift) [5] [https://news.ycombinator.com/item?id=12364805](https://news.ycombinator.com/item?id=12364805) [6] [https://news.ycombinator.com/item?id=13190314#13190657](https://news.ycombinator.com/item?id=13190314#13190657)

</comment><comment><USER55> i dont trust any piece of software that has all these made-up, unrelated, non- reflecting names. I mean come on, arrow, maya ? the main challenge about software engineering is correct naming. If you fail there you pretty much fail in the rest. Same goes for actually builtin name, "datetime". There is no such thing in real life as datetime. There is date and there is time. They are very separate notions and the root of the problem IMO is in trying to pile them together.

</comment><comment><USER56> Yeah.. datetime is one of the rare part of the Python API that I really hate using. It's just badly designed, e.g. simple things are hard and confusing.

</comment><comment><USER57> Slightly off topic:

> Maya never panics, and always carrys a towel.

Nice reference!

</comment><comment><USER58> I don't understand the author's effort on solving this "problem"... I wonder if he considered at some point make a contribution to stable open-source existing libraries like arrow that even claim inspiration on one of his projects for the API. What's not for humans on the arrow API? what are the arguments for basically start yet another time library from scratch?, why is making a contribution not an option? probably the author of arrow will love your contributions and will love to hear the arguments on the changes you propose.

<comment><USER59> As rich as it is to tell Kenneth to "consider contributing to existing open source libraries", I have to agree: what's so exceptional about this library when Arrow is already a thing?

[http://crsmithdev.com/arrow/](http://crsmithdev.com/arrow/)

</comment></comment><comment><USER60> Kenneth: It would be really cool if you could put in support for TAI and MJD.

</comment><comment><USER61> Great job, Mr. Reitz. I think I will use this in every project from now on. Thanks!

</comment><comment><USER62> This is a joke. The whole "library" is 200 lines, has 9 tests, Kenneth probably wrote it in a couple of hours. It is totally not necessary, because, there are a gazillion datetime libraries and still, this is on the front page?

Also:

        >>> dt = maya.now()
        >>> dt.datetime()
        datetime.datetime(2016, 12, 18, 19, 24, 50, 212663, tzinfo=<UTC>)

        >>> dt.datetime('Europe/Budapest')
        datetime.datetime(2016, 12, 18, 20, 24, 50, 212663, tzinfo=<UTC>)

I would not use it...

<comment><USER63> Just wanted to remind you that the entire Node community depends on one 11-line module. Lines of code is still a pretty meaningless metric.

<comment><USER64> Idk, pointing to issues like deep dependency within the Node community isn't the best argument. It's healthy to be skeptical of dependencies imo, especially in light of issues like the infamous left pad problem.

<comment><USER63> My comment wasn't about deep dependencies; it was about parent suggesting 200 lines is too few to be a legitimate library.

<comment><USER64> Ah, I see. Noted!

</comment></comment></comment></comment></comment><comment><USER65> Yet another library to handle dates in Python. Oh, boy... [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment><USER66> Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.

<comment><USER67> > It's puzzling why this doesn't wrap np.datetime64 instead. Perhaps to avoid > the numpy dependency. I've found numpy a bit heavy and wouldn't want to > depend on it simply for the sake of some datetime syntax. May be > boost.datetime or even numpy's implementantion on datetime, but that sounds > like a lot of maintenance.

<comment><USER12> Agree, 100%. E.g. numpy in a virtual environment can be a real pain. Best case, it takes a bit longer to install. Worst case, it's on a system that's missing some OS specific dependencies. "Works for me" is not okay for stuff on PyPI.

<comment><USER67> Hmm.. that's making me rethink that 'datascienceutils' project I put up on pypi.. May be work on getting it to stable version before pushing to pypi..</comment></comment></comment></comment>


HN PSA:  S-Corp Tax Returns are due March 15 - <AUTHOR>

S corps are a month earlier than personal returns, presumably because they're pass-thru so you need time to get the K-1 to the shareholders.<p>So make sure your 1120S (or extension) is filed by 3/15 <comment><AUTHOR> Posted because someone I know almost got burned by this his first year. _looks sheepish_

</comment><comment><USER2> thx. Done already!!</comment>


Watson cocktail recipes taste test - <AUTHOR> http://www.engadget.com/2015/05/15/drinking-with-watson/

<comment><AUTHOR> IBM's Watson suggests cocktail recipes...

"Why don't you make an old-fashioned with a splash of chicken broth and a slice of grilled chicken for garnish?"</comment>


For The YC & Techstars Rejects - <AUTHOR>

For those of you that plan to go ahead and build your idea anyway, do you want to setup a private forum for us to mentor each other?
We can share tips, ideas and questions and maybe even help beta test each other's stuff. At the end of it, we may even have a nice little portfolio of products to show off that may get a little attention.
What do you think? <comment><USER2> so an exclusive forum for rejects? Thats like the worst kind of wankfest if you ask me ;)

<comment><AUTHOR> lol, nice :)

</comment></comment><comment><USER3> I think that every time people suggest this kind of thing and it doesn't really work out. Just post your stuff to the main site, like those of us who simply never applied do.</comment>