The 3-year old "Implement RSS natively in Chrome" bug just changed to "WontFix" - <AUTHOR> https://code.google.com/p/chromium/issues/detail?id=33181 <comment><USER2> I just wish Google would have been straight-up about this, had a big blog post saying "Here is why we think RSS needs to be replaced, and we've got some big plans to replace it, which involve a, b, c, and existing standard d. It's a bit abrupt but we're coming out with X on timeline Y."

Not this cryptic bullshit. It's like breaking up with someone by just never returning their calls.

<comment><USER3> This has nothing to do with thinking RSS is dead or needs to be replaced, or whatever. It's just closing a feature request that was never going to be implemented. It never really made sense for the web browser itself to also be an RSS reader anyways.

<comment><USER4> _> It never really made sense for the web browser itself to also be an RSS reader anyways._

Well, I can understand that it might not have been for everyone, but it was super convenient to be able to read RSS "folders" in Firefox. I'm a Chrome/Chromium fanboy these days--I use it on all of my devices--but I still miss that feature. If you don't want to use a certain functionality, it's easy to just avoid it; you can't _ever_ use something that isn't implemented, though.

Clicking on a bookmark and seeing the most recent BBC headlines, for example, was awesome.

<comment><USER5> +1 why not just follow bbc on google+ now though?

<comment><USER6> Awful UI.

Some people want a random subset of news for entertainment. G+ is great for that. Here's a great big pile of recent stuff from everyone, a circle, or a community.

On the other hand, lets say I want to verify I read every story from certain sources (perhaps the BBC?) exactly, precisely once. I don't see a way in the G+ UI to "mark as read" or "only display unread" or whatever. Might exist or might be a weird way to hack it in, but its not intuitive.

For some reason option #1 is semi-popular among news readers, social networking, and old fashioned or online broadcasting, but option #2 is nearly universal among email clients and podcast clients. You'd never use an email client with a UI of "here's a random collection of some recent emails" with no way to tag them as read or deleted. I'd LOL at the idea of a podcast client with "here's a random cast that you may or may not have already heard"

Another horrible UI fail is time based. G+ can only do one linear "newest to oldest" sort. Even the dumbest RSS feed readers have some kind of tag/save/star feature. So you can skim the whole feed, star/save/tag good stuff for later detailed reading. Then once there is no "unread" left, start reading the star/save/tag stories in detail, perhaps much later. This "workflow" is impossible in G+ as near as I can tell.

Finally no one using the "RSS" workflow uses G+, so you get the chicken and the egg thing, where there's no demand for even the most primitive of workflow management in G+ because anyone wanting anything like that uses RSS. So the BBC is a bad example in that their social networking people are probably required to use both, but I suspect that 99% of my RSS feeds are not available in G+ because they self segregate by workflow. You'll need a bigger shock to the system than cancelling goog reader. I switched to newsblur once the crushing demand let up a bit. I'm not going to abandon everything I currently enjoy to watch cat videos on G+.

</comment></comment></comment></comment></comment><comment><USER7> There is no conspiracy here. That feature wasn't going to be brought back to Chrome, and should have been closed a long time ago. Shutting down Reader shined a light on this issue, so if they hadn't closed it before now is a logical time to close it.

Cutting off comments make sense as well as there isn't going to be constructive discussion at this point. Constructive discussion has already been had and a decision was reached. Having comments open at this point just inviting people to grind their axes.

</comment><comment><USER8> I honestly don't understand what all the fuss is about. Chrome browser will not support RSS natively, seems like they never had the intention to do so to begin with. Why are we up in arms about a product not supporting some specific feature? Why are we equating that with some evil plot?

      ...there have never been any plans to implement this natively in Chrome.
      I don't know why this bug has been left open for years, making it look as
      if we're considering this, when we're not.  It just gets people's hopes
      up, and then makes them bitter when years go by with no action.

This about sums it up for me, and it's completely understandable.

<comment><USER9> The fuss is about Google embracing/extending and then suffocating every WWW technology they can't shove at least 20 ads into.

<comment><USER10> Had Google actually even "embraced" RSS? I would say no. Reader isn't one of their core products and never was.

<comment><USER11> It wasn't a core product even when gmail had a prominent link to it at the top of the window? [http://guijournal.com/wp-content/uploads/2011/04/Gmail- more-...](http://guijournal.com/wp-content/uploads/2011/04/Gmail-more- menu.png)

<comment><USER12> Do you call everything that has an advertisement for it somewhere else a "core product"?

<comment><USER11> By "somewhere" you mean "at the top of every Gmail page"? Then yes, I'd figure that something Google prominently displays at the top of every Gmail page is probably pretty important to them.

I mean... when something is widely displayed in the middle of a list of things that includes

* Gmail

* Google Docs

* Google Calendar

* Google Photos

* Google Search

and nothing else, then I would naively consider it to be roughly as "core" as the other things on the list. You wouldn't? Why not?

<comment><USER12> I've never thought about a definition of a "core product" before, but it seems to me that it would be something that the company takes seriously, dedicates a lot of time on, and consciously depends on for user retention and growth. I don't think Reader fit any of those descriptions, and the placement alongside actual core products was an advertisement - a hope that it might become something more, but it never did.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> RSS has always been a threat to Google's core business. From Google's perspective, RSS is a technique that allows you to read news raw, stripped off of website ads. Ads are Google's only product business-wise.

They've closed the threat containment phase (Reader) and are finally openly out to kill it.

<comment><USER14> I see plenty of ads in my feeds. And nothing to stop Google from placing ads in Reader itself.

<comment><USER15> Most of the ad supported feeds I'm subscribed to have one ad post per week. Most ad supported websites have many ads _per article_. Guess which medium makes Google more money?

<comment><USER16> You can change this to:

1 ad per week on a RSS feed vs 1 ad per week on an entire website

and the answer would still turn out to be Ad Supported Websites. RSS users are an insanely small group compared to overall users on the web. So yeah, Google probably just decided that supporting RSS just isn't worth their money/time regardless of how it compares to its other services.

<comment><USER17> But you can't (reliably) run JavaScript in RSS which means no AdWords and no profile/context advertising. That's the stuff advertisers love, not one-size- fits-all banners

</comment></comment></comment></comment></comment><comment><USER18> I actually read RSS feeds --- using the Currents application (which is supported by Google and under active development; it's getting updates) on my Android Nexus 10 tablet.

[https://play.google.com/store/apps/details?id=com.google.and...](https://play.google.com/store/apps/details?id=com.google.android.apps.currents&feature=nav_result#?t=W251bGwsMSwxLDMsImNvbS5nb29nbGUuYW5kcm9pZC5hcHBzLmN1cnJlbnRzIl0).

So for those people who claim that Google doesn't care at all about RSS, Currents is certainly a counter-example.

And by the way, Google is a big enough company that to claim that a corporation as a whole as an opinion about any subject or any protocol is a little silly. Take for example, "IBM Loves Lotus Notes; therefore IBM must hate SMTP." Absurd. There is a part of IBM that make a lot of money off of Lotus Notes, yes. There are also lots of IBM engineers and former IBM engineers who hated it with a hot blazing passion. I'm aware of one IBM division which supplied its engineers with a Lotus Notes-free e-mail address because it was necessary for them to do their jobs. Specifically, interact with the open source community with a mail product that wouldn't destroy whitespace in patches....

<comment><USER19> Maybe Larry Page should write a public statement entitled "Thoughts on RSS".

<comment><USER15> Interesting connection you made there. Steve Jobs' "Thoughts on Flash" was about moving away from proprietary tech towards open web standards. What Google is doing with RSS is the complete opposite.

<comment><USER20> With which private technology are they trying to switch to ? I believe they are dropping RSS not replacing it.

<comment><USER15> Google+

</comment></comment></comment></comment></comment><comment><USER21> The old Google would champion RSS as an open alternative to proprietary social networks. Now they're trying to kill it.

<comment><USER22> Do no evil as long as Wall Street is happy - seems to be their real motto.

<comment><USER23> "Do no evil" is not the same as "Do every possible good thing forever."

<comment><USER21> Going out of your way to kill technologies that compete with your proprietary social network qualifies as evil in my book.

<comment><USER10> "Not going out of your way to support technologies you aren't interested in" is not the same as "Going out of your way to kill technologies that compete with your proprietary social network".

<comment><USER24> But when not supporting these open technologies very obviously benefits your proprietary social network, it is.

<comment><USER25> Okay, then Dropbox is evil unless they support open file syncing technologies?

<comment><USER24> If they are trying to shoehorn every man, woman and child into using their social network in a bid to track their respective activities in so as to sell the information to the highest bidder, yes. As it stands, Dropbox aren't so no they are not evil.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> On this subject I happened to experience something funny. Maybe one year ago I installed a chrome extension (from the official chrome store) to provide an RSS icon directly in the URL bar in order to subscribe to RSS streams. So far so good, then I don't know when, maybe months later I noticed I had some random popups with ads, it was very strange since I use adblock, I tried to find where these ads were coming from, with no luck. Then a day, I used the chrome inspector to analyze a web page and I observed something strange, on every pages I visited an external javascript was loaded, long story short, turned out the chrome extension was a kind of spyware loading a javascript on every pages I visited and sometimes rising a popup. Maybe it took me more time to find it because I only use chrome mainly for testing, my main browser being Firefox, but this is the kind of experience who removed the little confidence I had on the chrome store, and extensions in general, I'm very careful now on what extensions I install particularly extensions needing to be loaded on every pages I visit.

</comment><comment><USER27> I guess this makes it clear where Google stands on RSS.

I think it's sad. RSS is a lot more open than the alternative: Twitter.

Google seems to think that the result of an end to RSS will be good for them. Unless they are planning on buying twitter, I doubt it will be.

<comment><USER28> Why do people keep mentioning Twitter? It's not even vaguely related to what RSS does, any more than, say, a digital radio station you could tune iTunes to.

<comment><USER29> When you boil it down Twitter, Facebook, and G+ do the exact same thing as RSS,but they are all just easier,less flexible, closed and more centralized. You publish something and your subscribers receive it....seems at least vaguely related to me, imo.

<comment><USER30> How exactly is Twitter the exact same thing as RSS? I don't really see how someone tweeting about a new blog post being the same as what RSS does in any way other than being notified that a blog post has been written and possibly a title. I agree it is pubsub but that's pretty shaky. If the implication is that because we have Twitter then we do not need RSS .. I just think that's sort of ridiculous; is 140 characters the end of the road now? If not then Twitter is not a great solution to replace RSS. You can argue that RSS feeds have become like unread email but I think that is a different issue.

<comment><USER31> For non-techies Twitter achieves what they would use RSS for (notification of content) with convenient annotations. Yes they are very different, but that's how it works in principle. I doubt RSS will ever be completely gone, but the number of human readers was never high and is unlikely to go up in future.

Even apps that make use of it will be moving away from the user being directly aware of it.

</comment></comment></comment></comment></comment><comment><USER32> The past 72 hours: Google Reader shutting down, Chrome's RSS extension removed from everyone's browser _and_ the Chrome store, and "implement RSS natively" issue is now set to "wontfix". Way to be evil, Google.

Also posted as a tweet, because fuck being evil: <https://twitter.com/martindale/status/313148391624417280>

</comment><comment><USER33> That's a pretty whiny feature request. I read the first few dozen comments, and I don't really know what exactly was being requested.

It's clear to me that the right approach is an extension specific to your preferred RSS reader. I understand that some browsers have an RSS reader built it, but that still doesn't make it a core feature that's going to be used by a big portion of their users.

<comment><USER34> This feature request asks for two things to be native in chromium:

1\. have an indicator in the browser interface that an rss feed is available for the current page.

2\. have a preview of rss feeds rather than unstyled xml. It is just a matter of adding style for some xml files the way shiira[1] first did or the way safari[2], opera[3] or firefox do.

It is clear to me that the second is nice for the user even if the chromium developpers do not intend to implement a full rss reader as it just consists in making some common web documents readable directly in the browser, it is far more logical for a web browser to display rss than to display pdf... The first point is said to distract the user and clutter the interface so I can understand why it should be an extension (firefox voluntarily suppressed this indicator a few years ago).

[1]: [http://i1-news.softpedia- static.com/images/reviews/large/shi...](http://i1-news.softpedia- static.com/images/reviews/large/shiira_002-large.jpg) [2]: <http://media.arstechnica.com/images/tiger/safari-rss-big.jpg> [3]: [http://www.problogdesign.com/wp- content/uploads/2009/01/wind...](http://www.problogdesign.com/wp- content/uploads/2009/01/windowslivewriter3e889e18f9a4-12c7aopera-rss- big-3.png)

</comment></comment><comment><USER35> I'm starring the issue because I'm a slacktivist.

I'm also going to become less reliant on Google services because when they decide other open standards are less profitable than getting more eyeballs Google+ I don't want to be stuck like I am now.

<comment><USER32> I too have starred this issue.

</comment></comment><comment><USER36> Turning off any further comments on that bug is cute.

<comment><USER37> That's been standard procedure for issues getting a lot of off-topic comments, or have the potential for the same, for some time, and it's definitely welcome when trying to track the status of popular features/bugs. The point of issue comments is to contribute to getting an issue fixed or resolved, not to act as a discussion thread. It's quite clear this was a done deal for some time and there's nothing further to discuss in that issue.

<comment><USER38> Especially given that every comment gets emailed to everyone who'd starred the bug. Leaving comments open (and receiving "BUT WHYYYY" comments) just annoys the hell out of everyone who'd starred it.

</comment></comment></comment><comment><USER39> Yep, Goog wants you to read news, find out about the world only through its walled-pages, read the penultimate paragraph of this naive article sums it up! [http://gigaom.com/2013/03/16/why-google-killed-off-google- re...](http://gigaom.com/2013/03/16/why-google-killed-off-google-reader-it- was-self-defense/)

</comment><comment><USER19> This makes me even more reluctant to switch to Chrome from Opera.

I hope Opera continue to evolve their platform, WebKit engine or not. :/

<comment><USER40> Dissatisfied with webkit? Why not gecko(firefox)? =P

<comment><USER19> The engine switch doesn't bother me. It's just that Opera as a company is currently in flux, and they are discontinuing work in their Dragonfly web inspector, for instance, which does not at all suggest a good future ahead of Opera.

Firefox is pretty much the polar opposite of Opera in terms of features, although I like their work on open standards like Opera's.

<comment><USER41> > they are discontinuing work in their Dragonfly web inspector

Can i get a source on this?

<comment><USER19> <https://news.ycombinator.com/item?id=5299923>

</comment></comment></comment></comment></comment><comment><USER42> Does anyone know who email@example.com is?

<comment><USER43> Peter Kasting is the founding member of the Chrome team at Google.

<comment><USER42> I wasn't sure if the person that closed it was just some random guy, or a higher-up person at Google. Thanks for clearing this up.

</comment></comment></comment><comment><USER44> Google next move: Remove Adsense for RSS. By the way Google Currents is doing good job as feed reader and it is relatively new product. I don't think Google has declared war to RSS. Since most of its APIs is based on Atom. May be they want to make a transition to JSON based standard.

</comment><comment><USER45> "For a better user experience, we have migrated your feeds to a custom Google+ profile. We hope you will enjoy connecting with friends, family, and advertisers while reading news brought to you by Cuke(R)!"

</comment><comment><USER46> The 1600+ people watching that bug, and the millions using reader are the minority. RSS is for hackers, and Google doesn't want to invest in those people. (Us)

<comment><USER47> RSS isn't for hackers, it's for infovores. The same people who make the majority of pageviews on the internet, oh and also make most of the pages on the web. It's for a minority, but that minority is the very tip-top of the most hardcore users of the web. It's not going away.

<comment><USER40> It is worth mentioning a large part of the reason RSS is so reclusive is that none of the browsers kept the "subscribe via RSS" button in the nav bar Firefox had 6 years ago. Back then it was one click to add feeds to the browser, and anyone could use it. Now you have to go out of your way looking for it.

<comment><USER48> I remember the FF bugs for removing it suggested only 7 percent of people used it. What frustrates me is that 7 percent x web scale is not a small figure; and many of those were curators - prepping info for others.

<comment><USER47> _7 percent x web scale is not a small figure_

Not sure if they still do this, but Mozilla used to give new hires a little toy and say, "This is your million users; try not to abuse them too much." That concept is built-in to the culture there. Why take up space and memory for the 93% of users who don't use that feature, when an add-on can do just as good a job for the 7%?

</comment></comment></comment></comment></comment><comment><USER49> That's Chromium

</comment><comment><USER9> I can't believe we're going to see idiots actually wear google's spyware on their faces in a few months from now.

<comment><USER50> I'm one of those "idiots". You're welcome to say it to my face.

</comment></comment><comment><USER9> IF YOU'RE NOT PAYING FOR IT YOU ARE THE PRODUCT.

<comment><USER25> You don't pay for Hacker News.

<comment><USER51> The HN readership is one of many things PG sells to companies in return for equity in them. This should have always been clear.

<comment><USER25> Yes, my point is that being "the product" is not necessarily bad or wrong, and more importantly, that screaming that cliche on HN is very inconsistent.

</comment></comment></comment></comment><comment><USER52> Wow, I don't know about you, but this is amazing to watch.

It's like Google is operating without a head. It's turned vicious and acting offensively against a specific technology.

RSS will live on, of course. Amazing that Google is also so pompous.</comment>


Why I Pirate Media and How to Stop Me - <AUTHOR> http://demotalks.com/post/19735898770/piracy-drm-media-games-stop

<comment><USER2> "DRM is Costly and Promotes Piracy"

I don't think this really makes a difference. Louis CK's $5 show was released sometime ago as a test. It had no protection of any kind. Guess what? It was all over the torrent networks shortly after this.

People don't care about protection. They will pirate the media either way. No protection will just mean it will hit the networks immediately, which means the company that released it will lose out on those important first week/month sales.

There will always be excuses. That's the problem.

<comment><AUTHOR> Yea but the thing is, the amount of money you would have spent on DRM should be compared to the money you're gonna lose as soon as the product launches but this isn't easy to calculate.

If you take a look at movies for example, as soon as the DVD/BluRay for a movie comes out, you'll see it on file sharing sites on the very first day itself with DVDRip/BRRip in the title.

So, my point is, you spend money on DRM but your media gets pirated as quickly as DRM-free media. Maybe for some reason, your DRM-protected media doesn't get pirated as quickly but takes a couple days but that doesn't mean that during those days that people actually bought your stuff! It might mean that nobody bought it so there was nobody to share it. Or it might just mean that only people who always buy legit media bought it because I guarantee ya that if the media is popular, there are people who wait for it to arrive on file sharing sites and they'll never buy it unless it doesn't hit the scene for more than a few months.

So, the real thing to consider is money spend on DRM vs money lost on first sales because the rule is: If it's popular, it will be distributed illegally!</comment></comment>


Quintus - An Easy, Fun HTML5 Game Engine For Mobile, Desktop and Beyond - <AUTHOR> http://html5quintus.com/

<comment><USER3> Author here, just saw this pop up.

The engine isn't really in a released state yet and doesn't have a numbered released yet (darn lack of docs), but it's been used internally for a number of projects, most recently:

[http://www.html5gamedevelopment.org/StateofHTML5GameDevelopm...](http://www.html5gamedevelopment.org/StateofHTML5GameDevelopment/)

A rewrite of a couple of the parts (particularly scenes and some UI components) is a work-in-progress.

The primary goal of the engine is to be a small, modular, very JavaScript-like and to have a full test suite for the core parts of the system - <http://html5quintus.com/quintus/specs/SpecRunner.html> (this will help verify cross-browser behavior)

Forgot to add, this Engine came out of a book I wrote, and the examples for that book all run on Mobile: <http://mh5gd.com/>

<comment><AUTHOR> OP here - sorry for posting about it prematurely! Just found it quite interesting and blogged about it and posted a link here :)

<comment><USER3> No problem - I'm been sitting on the site and the Engine since October (building stuff with it instead of finishing it) - so this is a good kick in the butt to polish that sucker up.

</comment></comment></comment><comment><USER4> I think the most promising game engine for HTML5 is Cocos2D:

1\. Demo: <http://www.cocos2d-iphone.org/t/js-tests/tests/>

2\. Docs: <https://github.com/zynga/jsbindings#readme>

3\. A game example: <http://cocos2d-javascript.org/demos/dizzy-3-5>

The most interesting thing about Cocos2D with Javascript is that it takes advantage of the native application where it runs. For example, in iPhone it runs a native game with all the GPU acceleration but on a browser it uses the canvas object.

<comment><USER5> Unlike what you posted, the OP's engine runs fast and touch input actually works on my nexus 7.

I know that chrome for android is quite behind, but still.

</comment></comment><comment><USER5> Was saddened that the demo couldn't be controlled on my tablet. Is touch support planned? What about networked multiplayer?

<comment><USER6> According to the docs, Quintus does support mouse and touch input.

On my PC, the demo is controlled by keyboard only. Presumably, they wanted to make the code as small as possible so they didn't put touch controls in.

<http://html5quintus.com/quintus/docs/quintus_input.html>

</comment></comment><comment><USER7> Could somebody explain the "HTML5 game engine for mobile, desktop and beyond" part? Is it because it's HTML5, and will therefore work wherever a HTML5 supporting browser will work, or is there something more to make it "desktop" friendly?

</comment><comment><AUTHOR> via: [http://www.functionn.in/2012/12/quintus-easy-to-learn-fun- to...](http://www.functionn.in/2012/12/quintus-easy-to-learn-fun-to-use- html5.html)

The front-page of Quintus contains a simple demo written in approx. 60 lines of JavaScript code which implements a simple Super Mario-like game which you can test for yourself. You can play around with the code and check out the changes you make by yourself.

Documentation is not yet up to scratch, but it looks like a promising game engine.

Check out www.functionn.in for more web resources to keep you _functionn.in'_.

</comment><comment><USER8> At this point I'd like to suggest all the gamers try out our free Game Creation website... <http://playtin.com>

kthxbye

</comment><comment><USER9> this looks pretty great... I have been wanted to dabble in html5 games - <USER2> take Quintus it for a spin!

<comment><AUTHOR> the demo looks pretty awesome - esp. the no. of line of code vs the result produced. Tinkering with it myself. Promising.

<comment><USER10> Except when you reach the "tower", it starts spitting alerts and the only way out is to close Firefox (actually kill it). Meh :(

Also, I see the handler for collisions for the enemies, but where does it say that you can jump on them with no problem? Is that behaviour set somewhere explicitly?

<comment><USER3> That was sort of an accident but I left it that way as I'm working on a "enchancement" tutorial that makes it more like a standard platformer and adds in particle effects, etc.

</comment></comment></comment></comment><comment><USER11> wait, so basically I can create personalized games for parents to point their kids to on my server?

</comment><comment><USER12> The demo game has some questionable issues.</comment>


Django query expressions to add additional annotations - <AUTHOR> https://github.com/hypertrack/django-pg-utils <comment><USER2> Thanks for sharing. Very helpful.</comment>


Read some quotes, share ideas with strangers - <AUTHOR> https://fruit-fly.herokuapp.com/client/statusapp.html <comment><AUTHOR> This is actually a demo based on websockets and a distributed event bus[0].

Any feedback is appreciated.

[0]-[https://github.com/acionescu/web- events](https://github.com/acionescu/web-events)</comment>


Storing UTC is not a silver bullet - <AUTHOR> https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ <comment><USER4> This is the same as the alarm clock problem. When a user creates an event, what does that user _mean_? In the alarm clock example, what should happen if I've set my alarm clock 7am and then travel to a different time zone? In the conference event example, what should happen if the local time zone rules change, or daylight savings time comes into force? Did the event organiser print marketing materials that said "starts at 1000 UTC" or "starts at 10am" with a "in the local time zone" implication?

Events generally need to be locked to _something_ - whether that is UTC or a local time zone depends on the application.

The iCalendar standard ([https://tools.ietf.org/html/rfc5545](https://tools.ietf.org/html/rfc5545)) generally gets this right.

<comment><USER5> That's what annoys me about google calendar and most others. When I schedule an appointment most of the times it will be for the time zone i will be in at the time of the appointment. So when I travel and agree to meet people at 10 I want to enter it that way. But in most calendar apps everything gets shifted around as soon as I arrive at the new location. I would much prefer to have apps not shift stuff around unless I explicitly tell the app to do it.

<comment><USER6> Google Calendar does let you set the time zone in the 'More options' view, FWIW. I use it occasionally.

<comment><USER5> I know. But I want no time zone. When I plan my Germany trip next week I want to see the 10 am meeting there at 10 regardless of where I am.

It should operate like a good old paper calendar.

<comment><USER7> Its not that you want no time zone, you want to mark the appointment as "local" time. That could be useful, though I expect it would create as many problems as it solves.

The explicit timezone is crucial for conference calls that cross timezones. That is at least half of the appointments on my calendar (I coordinate projects between the US, Europe and Asia).

<comment><USER5> For international phone meetings this is good but for travel it's really bad.

<comment><USER7> I still disagree. I also travel a lot, and I set the meetings in the timezone _where_ the meeting is. It's not a paper calendar.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> There was another discussion here 10 months ago after Zach Holman's post: [https://news.ycombinator.com/item?id=17181046](https://news.ycombinator.com/item?id=17181046)

Sort of a summarization of most of the ideas here is:

* for clear instants like a system log UTC makes sense

* for times in the past (far enough in the past that you know your current TZ rules are correct) UTC makes sense.

* for the immediate past (near enough where your rules might not be correct) you might want to store zone as well.

For all cases of times in the past, remember that you're trying to record an _instant_. An exact unambiguous point in time that is the same irrespective of who is looking at it or where they are. For this UTC makes sense - people who see that instant converted to their local timezone are noting what their clocks would have shown at that instant, but everyone who will ever see it is always referencing the same instant.

FUTURE times are very different. There are times at which you want to reference a future instant, at which point you can just use UTC, but most often what you really have is "this is what I expect to see on my wall clock when this thing happens". That is a very different beast, because nobody knows what the timezone rules or geopolitical situation will be when that thing does happen.

You need to recognize the use cases where what you mean is " I expect to see XX:YY:ZZ on my wall clock when this happens" and just record that information as is, including as much information as you can about that wall clock - possibly which timezone it (currently) uses, where it is (in case the timezone itself changes) and then convert to an instant at the last possible moment, or keep updating your instant based on changing rules.

<comment><USER9> There is one thing that I ran into with past times that I think falls outside of this. When you record things like "first day of employment", you really do mean the date and not the datetime, and the date should be interpreted in whatever the local timezone is. Theoretically your first datetime if employment is what, midnight of the day you show up? Or is it 8am or whatever when you actually first step through the door? Each situation will be interpreted differently by the parties involved so best you can do is to store the date and the location/timezone of where they work, even though it's in the past.

<comment><USER10> The answer to your examples is that the conversion from date to datetime sometimes is ill-defined and you shouldn't assume that this can be properly done.

Legally, employment usually has a well defined start date and end date - <USER2> it often simply doesn't have a well defined start datetime and an end datetime, you might as well assume that it's undefined unless/until a particular situation forces you to get a court ruling for that.

<comment><USER9> How would you for example run payroll then for people who work 4pm-2am? You have to know whether the last two hours of the shift fall into one payroll period or the next, which necessitates that you be able to convert to a datetime.

</comment></comment></comment></comment><comment><USER11> Time is so messy, and that messiness becomes apparent when the yes/no, true/false world of computers tries to interpret things.

The blog posts brings up a lot of good points about time zones changing, and the comments make even better points about people moving across time zones. Something that confounds me occasionally is the concept of "local human time" because there are all sorts of ways that humans tamper with time.

Lawmakers, for example, that are required to pass certain laws by a particular date will sometimes unplug clocks in the legislative chambers to stop the legal passage of time while negotiations continue. You end up in a situation where, on paper the next day or week, 134 laws were negotiated, voted on, ratified, re-voted, passed, and signed all at exactly $date:23:59:59. A physical impossibility, but a legal fact.

Or, as I explore the more interesting corners of America more, there are entire towns and regions that ignore their official time zone and every house, business, church, pharmacy, etc... is on a more convenient time for the locals. The only place you see the official time is at the post office.

People are messy. Time is messy. People * time = a complete mess.

<comment><USER12> > Lawmakers, for example, that are required to pass certain laws by a > particular date will sometimes unplug clocks in the legislative chambers to > stop the legal passage of time while negotiations continue. You end up in a > situation where, on paper the next day or week, 134 laws were negotiated, > voted on, ratified, re-voted, passed, and signed all at exactly > $date:23:59:59. A physical impossibility, but a legal fact.

Is this internationally accepted or a USA-only thing? It seems like fraud to me.

<comment><USER10> I don't know about that particular description, but it kind of makes sense - two bills passed on 27th March parliament session are passed on the same "business day" even if that day gets long and one of them was voted on five minutes before midnight and the other was voted on five minutes past midnight; and if there are some mandated legal delays (e.g. you have x days to before they'll be in force or something) then both bills will be treated as if they were passed on the same date.

This also matches common usage - if I tell you what I did on a friday night, it'll include both things before and after midnight.

There are also parallels in banking where business days don't align with calendar days, and you may have (depending on regulations and agreements) either a "long friday" or "long monday" where an action that's physically performed on a sunday will be treated with an effective date of friday or monday respectively; or possibly events after the closure of a business day may be legally treated as happened in the day after.

</comment></comment></comment><comment><USER13> I did a full switch to Postgres like 2 years ago, and a decent chunk of the decision was `timestamp with timezone` saved me a huge amount of headaches working on multinational services

Use timestamp with tz, drop Unix timestamps and use ISO8601 DateTime format across the application ezpz never look back

<comment><USER14> Unfortunately `timestamp with time zone` is misleading and crippled.

When you store something as timestamptz, postgres converts it to UTC and "loses" the timezone part.

The only difference between timestamptz and timestamp is that when postgres is returning the timestamptz to you, it converts it back to _your local time zone defined by SET TIME ZONE_ (and not the time zone it was originally stored in)

So basically if you store a timestamptz, you cannot convert it back to the local time, as the local time is never even stored.

I personally had to add a second `timezone` column to my table to store the timezone of the date.

<comment><USER15> I wouldn't go so far as to say the timestamp types are _broken_ , just confusingly named. `timestamp with time zone` signifies an absolute point in time; `timestamp without time zone` signifies a timestamp relative to some unspecified time zone (which you must store separately, as you point out). The builtin functions universally adhere to these semantics.

E.g., when you do store the timezone separately, use `timestamp without time zone`: `time AT TIME ZONE timezone` [1] only does the right thing (i.e., interpreting `time` as relative to `timezone`, and producing an absolute time corresponding to it) if `time` is `without time zone`. (If `time` is `with time zone`, it produces the local time corresponding to the absolute time `time`, which is mathematically exactly the opposite of what you want.)

[1] [https://www.postgresql.org/docs/current/functions- datetime.h...](https://www.postgresql.org/docs/current/functions- datetime.html#FUNCTIONS-DATETIME-ZONECONVERT)

<comment><USER14> I said they are crippled, not broken.

Unfortunately the poor naming is a big faux pas.

I _really really_ expected _timestamp with time zone_ to store the _time zone_.

</comment></comment></comment></comment><comment><USER16> Storing UTC (or rather TAI) is a silver bullet for "system" times - <USER3> that need to happen on a regular schedule, where we care how much time has passed between one instant and another, or things where we want to record at what instant something happened, and correlate system events with each other.

Indeed it doesn't solve the problem of handling user-inputted "human" times correctly. But that is a much rarer case than needing to handle "system" times. Many - probably most - applications never need to handle a "human" time at all.

<comment><USER17> I prefer TIA over UTC and wish it was widely used.

Leap seconds mean the same UTC time can happen twice if we fall back a second, or a UTC time may never happen when we skip ahead a second. Leap seconds also mean that epoch milliseconds derived from UTC do not represent milliseconds between the timestamp and Jan 1 1970 unless the conversion is aware of all leap seconds. Leap seconds are prescribed every six months with six month notice. There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.

I'm pretty happy with ISO-8601, but dates after the year 10,000 will not sort lexicographical. A 64 bit signed int storing milliseconds since Jan 1 1970 covers 29225733 B.C to 29229672 A.D

<comment><USER18> >There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.

Isn't this an argument against using TAI in certain applications though? i.e. if you're designing a system which relies on non-leapsecond-updated devices to be in sync with devices that are capable of being updated, you should always design as such to accommodate the former rather than the latter?

<comment><USER16> No? It's an argument for using TAI,because devices that use TAI do not need leap second updates - a clock running TAI that was started in 1970 and never updated will show the same time as a clock running TAI that's started today (or one that was started in 1970 and updated continually), whereas a clock running UTC that wasn't updated will show a different time from one that was updated.

</comment></comment></comment></comment><comment><USER17> > Time zone boundary changes and splits

The united states will experience this soon. California and Washington are independently seeking to end daylight saving time. There is no America/Portland or America/Seattle so Washingtonians and Oregonians are using America/Los_Angeles. Unless Washington, California, and Oregon end Daylight savings on the same schedule we'll have to add new id's and users will have to change their configuration, and we'll still have issues described in the link.

</comment><comment><USER19> The distinction between different kinds of time is really pretty key to having a clear understanding.

Civil time is different from atomic time and different from sidereal time or solar time.

Civil time is how people, businesses, and governments organize and plan their activities.

Atomic time is monotonic, physical, and "more objective" / less dependent on legislatures :)

Sidereal time is about the orientation of Earth relative to stars. It's really important if you're an astronomer.

UTC is a civil time standard based closely on TAI, an atomic time standard, _except_ it gets corrected to be within 1 second of UT1, a sidereal time standard. It is basically _the_ civil time standard and it is a little compromise to make a civil time that advances like atomic time but also does not desync from sidereal time.

Different administrative regions use offsets from UTC to determine their local civil time.

If you're writing an application where people plan future activities and you really want to "get things right / not surprise users", you probably need to store times in the appropriate civil time standard, make it apparent _which_ civil time standard is canonical per activity if people are being coordinated across administrative regions that do not synchronize their standards, and ensure that your application can find out about planned changes to civil time in any of the administrative regions of interest.

</comment><comment><USER20> This is also a related article:

[https://zachholman.com/talk/utc-is-enough-for-everyone- right](https://zachholman.com/talk/utc-is-enough-for-everyone-right)

It is more high level but a very good read on the subject.

<comment><USER21> Autoplaying video right at the top. Never closed a tab so fast.

<comment><USER22> Funny you should say that, here's an excerpt from the article:

> And then someone will calmly quote this passage in response, quietly pleased > with themselves that the initial commenter was rude and certainly didn't > read the post at all. Then a third person will chime in on the thread saying > the author was playing you all like a fiddle anyway, and the real problem is > that the post was way too long to start with.

It's funny that it predicts my comment as well, touché.

</comment></comment></comment><comment><USER23> I noticed another use case regarding photos on the filesystem. I like to see them in their local datetimes, rather than the absolute time in my current location, but don't believe linux filesystems supports that.

For example if I travel and take photos I don't want their mod times to be of those back home, which can be in the middle of the night or wrong day.

Have been moving them to my local timezone via a time shift, but not sure that is the right thing to do. Now they are in my timezone, but if I move one day, will I have to update all my photo times? Even with exiftool and DateTimeOriginal, that's more file updates than I'd like to do.

<comment><USER24> The filesystem is doing the right thing here by accurately storing the original point in time when the photo was taken (or at least it was before you shifted it). If two files were modified simultaneously then they should have the same mod times, even if the changes occurred on opposite sides of the planet. The problem is all in the presentation layer; you want your file explorer (or 'ls') to display the times in their original timezone, not the timezone you're currently in. There is an EXIF tag for the time zone offset but support for it appears to be limited. The original timezone could be inferred from the EXIF location data, however, if you have that enabled.

</comment></comment><comment><USER25> What is more obscure but equally obnoxious is that dates are also affected by time zones.

For instance, Emperor Hirohito went to bed on December 8, 1942. A few hours later, bombers attacked Pearl Harbor at December 7 local time.

<comment><USER26> Things get really fun when you are asked to be able to sort these ambiguous dates.

Let's say Event A happens in New York (Eastern Time Zone) at 2018-12-08 02:00 UTC, and is recorded as occurring on 2018-12-07 (with no time) local time. Then let's say Event B happens in London (GMT) at 2018-12-08 01:00 UTC, and is recorded as occurring on 2018-12-08 (with no time) local time. Which event happened first? If we know the UTC times, a reasonable person would say Event B happened first. But if we just have the local dates with no times, we either say that Event A happened first, or we say we don't know.

This is a real problem I have to deal with and it is a pain. One user says A happened first, another says B happened first, another says A and B happened at the same time, and I say "give me the UTC time or you don't get this feature" :)

<comment><USER27> Then you can talk about Russia's Gregorian calendar switch.

The day the Russian revolution began on 25 October 1917, it was 7 November 1917 in England.

<comment><USER28>
        $ cal 9 1752
           September 1752
        Su Mo Tu We Th Fr Sa
               1  2 14 15 16
        17 18 19 20 21 22 23
        24 25 26 27 28 29 30

<comment><USER27> Not in Russia that wasn't the calendar in September of 1752! Apparently the `cal` command assumes certain geographic areas when it shows you calendars...

<comment><USER28> It assumes you follow the calendar of the British Empire

[https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750](https://en.wikipedia.org/wiki/Calendar_\(New_Style\)_Act_1750)

</comment></comment></comment></comment></comment></comment><comment><USER27> I believe the problems described here are with _future_ dates, and future timezone definition changes you don't know about 'right now' when you converting a local time to UTC for storage.

The nature of the problem is that when you convert from a local timestamp to UTC, you might have been "wrong" in the conversion. Or, more specifically, it may have been as correct today, but it may _become_ wrong some time in between now and when the timestamp occurs, because of future time zone definition changes. A future timezone definition change may mean you should have converted to UTC differently, which you couldn't have known because the timezone definition change happened after you converted. (Usually statutorily; sometimes maybe because your timezone data was wrong and was later corrected?)

I don't believe these problems apply to _past_ dates or "right now" timestamps. Unless your timezone data is wrong I guess.

Does this seem right?

<comment><USER29> I think it's close.

As the article explains, though, present and past timestamps can be impacted too - your timezone library may be out of date at the moment you save the timestamp, or in some cases the legal body defining the timezone may reach into the past with a timezone change.

<comment><USER27> How can a legal body possibly change the timezone retroactively?

All those people on Monday that _thought_ it was 1pm, it turns on Tuesday we decided it was actually 2pm when they thought it was 1pm. But nobody could have known that on Monday. So they've got to... go back and change any times they put on documents on Monday? How does that make any sense?

But incorrect timezone data or implementation is too real, true.

<comment><USER29> I should also clarify that conceptually, even if you keep your copy of the tzinfo database obsessively up-to-date, you could still experience what appear to be retroactive updates, per the "Theory and Pragmatics" document from the tzinfo project [1].

That's because some governments are pretty sloppy about announcing their timezone changes in advance. It's compounded by the tzinfo DB being maintained by volunteers (who can't spend their lives obsessively gathering timezone change announcements the instant they're made), and the lead time necessary for software projects to update their tzinfo instances [2].

So, while retroactive changes may not be consciously made often or ever, it's certainly an effect that happens in practice.

1: [https://data.iana.org/time- zones/theory.html#accuracy](https://data.iana.org/time- zones/theory.html#accuracy) 2: [https://codeofmatt.com/on-the-timing-of-time- zone-changes/](https://codeofmatt.com/on-the-timing-of-time-zone-changes/)

<comment><USER27> Ah, good point! With reference links, thanks!

</comment></comment></comment></comment></comment><comment><USER30> Of course. The real advice should be:

\- store past dates in UTC

\- store future dates in the format that makes sense, based on what the truth is. Scheduling event at 9AM local time? Use local time. Determining when the spacecrafts meet? Use UTC (or Federation Standard Time if you prefer ;) ).

</comment><comment><USER31> I think it depends on what the time represents.

When a user inputs a time, let's say for an alarm, this is always "wall clock", and this is what you store. The timezone can be stored too, but this is also dynamic. For example, a user put a conference in a calendar at 7 am, this is dependent of the user location the day of the conference.

For app following the user, this is simple (like a mobile app), you just use the current timezone of the system the app is running on, but for a distributed system (client server), it might be complicated to pick a timezone and is dependent of the application.

For computer times (like logging, cron...), just use UTC.

</comment><comment><USER32> Birthdays are a bit tricky too, say you want to show if it's someone's birthday today. In UTC you can be off by a day, so you just have to store the date without the TZ and treat it local in every TZ.

</comment><comment><USER33> I don't see how the countdown timer can fail to reach zero when the conference starts, if we have calculated the correct number of seconds between now and the conference, and do not change the conference time based on whether or not daylight savings time is canceled, to preserve it apparent local time.

If we decide that the conference's start may be a moving target based on changing DST rules, then our coutdown timer cannot smoothly count down. At every tick, it has to evaluate the amount of time left to the conference start, and show that. The conference start's local time is always converted to UTC based on the current rules; when the rules change, it jumps by one hour and so the countdown timer adjusts itself at the next tick to show an extra hour.

You can't smoothly count-down toward something that starts at X or at X + 1h, and you don't know which until later.

<comment><USER34> Which is why storing the time data in UTC isn't a correct approach, because it just become countdown timer. A user may need to be reminded at specific time in a future, on a specific time zone. And it can't be reached by merely put a countdown timer.

<comment><USER33> That doesn't follow. If the DST rules change, then, effectively, any event whose local time stays the same has actually moved. The sun will be in a different spot of the sky when that meeting is held than it would have been.

All the dates stored in UTC which move due to a DST rule change have to be traversed and updated, as do any dependent countdown timers. That doesn't mean it wasn't "correct" to store them that way.

"Correct" means that we handle all the cases in our specifications and design, and they are translated to code without mistakes.

People like countdown timers. If there is going to be a countdown timer to an event whose time is uncertain, that countdown timer has to update itself when the exact time is pinned down. Until then, it should probably use the shorter countdown so that it errs on the side of too early. It has to be updated whether the time is stored as local time or as UTC. The behavior of the countdown timer cannot depend on how the time is stored in some database.

</comment></comment></comment><comment><USER35> Dont confuse UTC with GMT.

Store absolutely everything in UTC, do all calculations on UTC, and show in whatever timeunit the user wants. The one edge-case where user inputs a local time thats is not unique (repeated hour due to daylight savings time) can easily be solved consistently, and often is not even a problem at all.

<comment><USER36> I used to think that, when I was young and naive, which was maybe a month or so ago.

Here's a use case: You and I are agreeing to meet at a given landmark. This could be any landmark in the United States, just to keep it simple. The user experience is: you propose that we meet at <landmark> at 4 PM tomorrow, and I agree. This happens on a website.

As far as you, me, and most of the system is concerned, the only sensible way to store that time is as a timezone-agnostic, UTC-agnostic local time: "2019-03-28T16:00". That's because, for the system to store that time as UTC, we have to know the UTC offset of every landmark in the United States _at any point in time_ (which isn't an easy problem!) and consistently, correctly convert between UTC and that local time every time it gets displayed anyway. If we screwed up the UTC offset when we stored it the first time, we have to change the UTC time.

Now, if there's an additional constraint that you can only schedule meeting times that are actually in the future, you have to know what times constitute "the future" relative to the UTC offset of the landmark, so you don't get out of needing a comprehensive UTC offset map of the United States. But if you screw that up, you just end up putting an irrelevant or impossible meeting time in a dropdown and maybe dealing with some users attempting to time travel. Even that is a failure mode that users will somewhat understand, but most of the time it won't matter unless users are scheduling within the same time window as your UTC error.

If you stored it in UTC, you'd be screwing it up _all the damn time_ until you fixed your UTC offsets, at which point previously-working data would be incorrect because someone would schedule a meeting 8 days out in one of those geographic regions for 6 PM and suddenly wonder how it got shifted to 5 PM for no reason.

Now, if we're scheduling a meeting _online_ , and videoconferencing instead of traveling to the Navajo Reservation in Arizona--of course we store it in UTC. And if some of us are traveling to the Navajo Reservation[1] and some of us are dialing in from Newfoundland[2], we're all fucked anyway.

[1] The Navajo Indian Reservation spans multiple states, including Arizona. Arizona does not observe DST. The Navajo Indian Reservation does. However, inside the Arizona portion of the Navajo reservation, there is a Hopi Indian Reservation, which does _not_ observe DST. Inside of the Hopi reservation, _there is another part of the Navajo reservation that does observe DST_.

[2] Newfoundland's UTC offset isn't an integer number of hours, there's an extra half hour in there. Enjoy!

<comment><USER35> Your examples indeed show common problems with several approaches when place is coupled to a time and then proceed to ignore the place (of meeting or user) when converting times.

I should add that where we store UTC that concerns a place, we also know/store that place in lat,long (or anything that resolves to this) and use that to show it in any timezone, to any user in any timezone, ..even in any era (yes places can change timezone).

</comment></comment></comment><comment><USER37> I think a more correct title would have been "date storage antipatterns"

storing in UTC is fine as long as your clients are time zone aware and can convert to local and send timestamps with time zone so that the server can convert back to UTC.

the "options" provided are just examples of how not to do it.

</comment><comment><USER38> We simply use the google timezone API to find the event's local timezone, for physical events, then store UTC. For non-physical events, we store UTC based on the timezone of the user agent that made the request, taking into account daylight savings rules. On the extremely rare occasion that rules change between when the event was scheduled and when it takes place, we don't have a system in place, so the time would have to be updated manually.

NOW... it gets even more interesting for recurring events. Does 11AM on Tue mean 11AM on Tue after daylight savings? How about events like Shabbat candle lighting times that depend on when the sun sets?

It took us a while to do all these. Does anyone know a good non-API solution to timezone calculations / shapefiles feed?

</comment><comment><USER39> I don't understand the described result for Option 1 or how having stored in UTC creates a problem there. It would seem to me like when the government changes the rules for local time, they are effectively moving the (real, not clock) time for the conference. It would seem like there is enough information stored in the database that installing the new time zone rules should cause the timer to move to accommodate this, as long as addresses don't get redefined (a different issue with that storage model). I don't see why the timer would not instantaneously jump an hour to correct itself when it becomes aware of the new rules or why it wouldn't hit the zero at the right time.

</comment><comment><USER40> What about:

* ID: auto-incremented integer

* Name: string

* StartTime: date/time in UTC

* Address: string

* TimeZoneId: Europe/Amsterdam

* RuleEffectiveTime: date/time in UTC

The rule effective time represents when the start time was last changed, converted to UTC.

Next, create a time engine that can convert between events (time + location). The engine can convert events to different time zones in different epochs, to UTC, or the other way around, because it knows all the rules, and when the rules changed throughout history. A simple API will handle things:

time time_engine.parse_time(rule_effective_time_event, string_representation)

String time_engine.to_presentation_string(rule_effective_time_event, time_value_utc)

Where time_event is a tuple consisting of the rule effective time, and the timezone whose rules to apply.

When the venue changes, you update TimeZoneId. When the start time changes, you change StartTime and RuleEffectiveTime. The time engine would only be invoked to present the start time in current time + zone format for the user to modify in their own temporal space, then to parse the changed time back to UTC using the user location + new RuleEffectiveTime (which is now).

Timezone rules are fixed as events in time and space, so every rule effective time + time zone + utc_time will uniquely point to a specific time zone rule, which means that the rule itself doesn't need to be stored in the database.

Timestamps are also fixed, and should never change (unless the user changes the time for the meeting, of course).

You could build the time engine to preserve absolute time (14:00 becomes 15:00 after the rule change), or to preserve local time (14:00 remains 14:00 after the rule change, even though it's technically a different time). You could even change how the engine behaves after data has been created, since it's only affecting how things are interpreted locally to the user. The data remains the same no matter what.

The database's role is to store data, not to decide rules. Store the data, not the rules.

</comment><comment><USER41> Storing UTC is still usually right because in many cases rather than dealing with calendar times, developers are dealing with instants in time that have already passed/are passing (creation/update timestamps, logs, etc.) I think this basically is only important when you might store a date in the future. If you have timezone rules incorrect for present or near past dates, well you're going to have a hell of a time dealing with that no matter what you do, really.

Handling calendar times and recurring times have their own complications.

</comment><comment><USER42> In our application we can compare charts of timeseries data that may originate in many different places in the world.

If you want to compare e.g. two charts of temperature over a 24-hour period between two places, you want noon for both to be in the same place on the X-axis. So you want to use local time of both places.

But if you only store UTC, you don't know local time.

No need for tzinfo changes or travelling through time zones.

</comment><comment><USER43> If you have ever done anything seriously with time zones you store everything UTC and must use a library to translate. The problem is it is geopolitical, so the time zone conversion result can vary based on the date itself as well as the physical location. For example DST was changed in 2007 in the US, there is no option but to programmatically translate.

<comment><USER44> Even if you store in UTC and use a library you have to know what the user mean when they create a recurring appointment.

I currently have several recurring alerts in my calendar app. One of them is an alarm everyday at 10 p.m. This must be in local time everywhere I go. Another is a conference call at 10H30 a.m on Wednesdays, Pacific Time (not my timezone). If you treat them the same way one of them will be wrong when I travel.

</comment></comment><comment><USER45> An interesting case was time stamps for photos on a global photo sharing site. UTC and conversion to local for display was the normal pattern. We decided to change this to display the time of the photo local to where the photo was taken. This where-taken and when-taken were paired. It made new years' and other holiday or time of day shots make sense.

</comment><comment> crooked-v The "time zone version" issue mentioned in the article isn't quite as hard as it looks, as time zone-based libraries will (if done right) include the whole history of time zone changes too. For example, java.time and the JS lib moment-timezone both use a full time zone history to convert to/from UTC, not just current offsets.

<comment><USER46> I think you've misunderstood what's changing here. It's not a matter of time zones not knowing that rules vary across time. It's a matter of knowing that "the rules for 2022" vary over time as well - in that the rules I might _predict_ for 2022 may well not be the case now.

"Time zone history" (in every platform I've seen) does _not_ mean "knowing what the rules for 2022 were in 2019". They mean "getting things right according to all the currently-known rules, across all of history". That's very different.

</comment></comment><comment><USER47> It's because a date and a time are not the same thing. Storing date as a UTC time is of course always wrong.

</comment><comment><USER48> I like unix time. But its not perfect either. Soon we will have a new y2k problem where unix time can no longer fit into an integer. Anyone remember the y2k problem ? People predicted major catastrophes as the year was encoded with two digits. But no one is talking about unix time.

<comment><USER49> This will certainly be a problem for older apps, but anything I've done in the last 10 years I've been dev'ing, literally every library I've used for Unix time uses a 64 bit integer, which should last for a few million years.

<comment><USER48> Some programming languages still don't have 64 bit integers!

</comment></comment></comment><comment><USER50> Am I right in thinking that if you always store in UTC, when the clocks go back you will get overlapping data?

e.g. if you store your logs with a UTC date you'll see interleaving logs for the extra hour, or if you read sensor data or something like that you'll get double readings?

<comment><USER51> No? Or not necessarily, at least. For example, pytz (a Python timezone library) offers "is_dst" flags for exactly that purpose.

      >>> loc_dt = datetime(2002, 10, 27, 1, 30, 00)
      >>> est_dt = eastern.localize(loc_dt, is_dst=True)
      >>> edt_dt = eastern.localize(loc_dt, is_dst=False)
      >>> print(est_dt.strftime(fmt) + ' / ' + edt_dt.strftime(fmt))
      2002-10-27 01:30:00 EDT-0400 / 2002-10-27 01:30:00 EST-0500

[https://pythonhosted.org/pytz/#problems-with- localtime](https://pythonhosted.org/pytz/#problems-with-localtime)

</comment></comment><comment><USER52> On a related note, I do all of my personal time in UTC. All of my phones, clocks, watches, computers, calendars are set to UTC. It just makes everything easier for my personal projects.

</comment><comment><USER53> [https://github.com/evansiroky/timezone-boundary- builder](https://github.com/evansiroky/timezone-boundary-builder)

</comment><comment><USER54> I have always thought that time would be best stored as milliseconds from TAI. It is a measure that is universally constant and unambiguous.

</comment><comment><USER55> As in save geographically bound event calendars with local time. Problem solved.

</comment><comment><USER56> Store timestamp and convert it to whatever the user wants.

</comment><comment><USER57> Why is this even a problem? This is the entire job of tzinfo which any respectable language uses to resolve datetime conversion.

</comment><comment><USER58> The silver bullet isn't storing UTC, its getting rid of timezones. Why not just have a universal clock and call it good?

<comment><USER59> Because people need to tell each other about time-related things while being globally distant.

"Call me at dinnertime, say 7." "My 7 or your 7?"

Is a lot easier than

"Call me at 0400" and having both parties do offset math in their heads.

<comment><USER60> I don't understand. Your first example is the one where people need to do offset maths. The second example requires no offset maths as it's 0400 for both parties and they both already know what they're doing at 0400 if we didn't have timezones.

</comment></comment></comment><comment><USER61> Why not just store both UTC and timezone right into the database ?

<comment><USER62> Because for future events whose time is fixed in their local timezone, you can't be certain that the timezone's offset from UTC on that future date is going to be the same as what you currently think it will be.

</comment></comment><comment><USER35> PSA: this article is confusing UTC with GMT.

<comment><USER17> The author did not confuse GMT for UTC.

I live in Seattle, I set a reminder on my phone one minute before new years 2021.

        date --date "2021-01-01T07:59+00:00"
        Thu Dec 31 23:59:00 PST 2020

Currently Washington follows daylight saving time so we'll be using PST on new years eve.

Washington lawmakers are considering a bill to end daylight saving time. If it passes then new years eve 2020 will be PDT, not PST

2021-01-01T07:59+00:00 is midnight PST but it is 1:00 AM PDT and my alarm will be off by an hour.

</comment></comment><comment><USER63> This really buries the lede, which is 'Use timestamps'.

<comment><USER64> Which would have the exact same problem as UTC.

For most use cases when a users enter a datetime in the future, they do not care about how many seconds from 1970-01-01 that point is, they care that it occurs at exactly 12:30 on that particular day.

<comment><USER65> If you _really_ cared about how many seconds have passed since 1970-01-01, you'd need to use TAI not UTC.</comment></comment></comment>


Google changed the Favicon - <AUTHOR> https://www.google.com/favicon.ico

<comment><USER2> Already posted, discussion <http://news.ycombinator.com/item?id=4379867> and <http://news.ycombinator.com/item?id=4375713> , and Google's blog post about it <http://news.ycombinator.com/item?id=4375713></comment>


SpaceX reveals the controls of its Dragon spacecraft for the first time - <AUTHOR> https://arstechnica.com/science/2018/08/spacex-reveals-the-controls-of-its-dragon-spacecraft-for-the-first-time/ <comment><USER2> The important bit for me was:

> . . . touch screens selectively display the necessary controls during flight > and are the primary interface astronauts have with the vehicle. Below are > two rows of manual buttons, 38 in total, that provide back-up control of the > spacecraft. Many of the buttons are situated beneath clear panels, intended > to never be used, because they are often the third option after the touch > screens and ground control of the Dragon.

I wonder how much they've tested situations where those 38 buttons are all astronauts have to use in an emergency situation, both with/without gloves.

> One control stood out—a large black and red handle in the middle of the > console with "EJECT" printed in clear white letters above it. This initiates > the launch escape system, which rapidly pulls the spacecraft away from the > rocket in the case of an emergency during the ascent into space. It must be > pulled, then twisted. Normally the flight computers would initiate such a > maneuver, but the prominence of the escape system handle underlines its > importance. Notably, after the vehicle reaches orbit, this control becomes > "deadened," such that accidentally pulling it in space would do nothing.

Similarly, I wonder if removing the judgment call (even at the risk of accidental usage) from the eject handle is wise...

This article wasn't as design/UX-focused as I'd hoped from the title.

<comment><USER3> For all of NASA's faults, realistic practicing emergencies in a simulator is something they get right. The crew have already started this process with the Dragon, and will have been pressing these buttons while dressed for space and in the middle of simulated emergencies.

(Fun fact, the buttons in the Soyuz capsule are currently operated with a astronaut held stick during launch and landing. [https://space.stackexchange.com/questions/4114/why-is-a- stic...](https://space.stackexchange.com/questions/4114/why-is-a-stick- required-to-operate-soyuzs-computer))

As for the launch abort handle not working in orbit - moving the capsule rapidly away from a malfunctioning rocket behind you doesn't really do you much good once there is no rocket attached to the capsule anymore. You would do a different sequence of actions to return from space in an emergency.</comment></comment>


Git info in your ZSH Prompt - <AUTHOR> http://briancarper.net/blog/570/git-info-in-your-zsh-prompt <comment><USER2> I've been really digging oh-my-zsh recently for extending zsh, comes with a great plugin architecture and all sorts of cool shit: <http://github.com/robbyrussell/oh-my-zsh>

<comment><USER3> Beat me to the punch... Oh-my-zsh ftw. Robby Russell has a great blog about rails development too. <http://www.robbyonrails.com/>

</comment></comment><comment><USER4> Note also that there's a more feature complete version that accomplishes the same tasks in the contrib directory of git ([http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/comple...](http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git- completion.bash;h=f83f019ca91a2611f5bd3474ccf6d10081320c4c;hb=HEAD)).

It's implemented in bash but I use it with almost no modification with the Korn shell.

<comment><USER5> You linked to the wrong version, given the topic of this thread.

Recently ZSH support has been added to git-completion.bash, but it's still only in the "next" branch of git: [http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/...](http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/completion/git- completion.bash;hb=next)

</comment></comment><comment><USER5> You can also use Git's own __git_ps1 from git-completion.bash in either bash or in zsh (see my other comment). Here's an example of it in use: <http://github.com/avar/dotfiles/blob/master/.bashrc#L86>

It doesn't give you info about whether you have staged files (but maybe it should). But it gives you a bunch of other neat stuff, like whether you're in a git-rebase or git-am operation

<comment><USER6> It definitely can tell you whether you have staged files, because I use it for that among other things. I don't remember how I turned that feature on, but it wasn't hard. Perhaps someone will chime in with the details.

<comment><USER4> Just add the following lines in your .bashrc:

        export GIT_PS1_SHOWDIRTYSTATE=yes
        export GIT_PS1_SHOWUNTRACKEDFILES=yes

<comment><USER5> Thanks. I didn't know about those. I've configured them in my ~/.bashrc now: <http://github.com/avar/dotfiles/commit/43454870>

</comment></comment></comment></comment><comment><USER7> Wow, am I the only person who prefers a shell prompt of just "$ "?

I have a bunch of abbreviations for common git commands, though, so I guess it balances out.

<comment><USER8> You're not- I can't stand waiting 3-5 seconds every time I hit enter, just so I can have a more verbose prompt that tells me things I already knew.

<comment><USER9> The one I wrote, for Bash, uses SIGALRM (via the Time::HiRes perl module) to time out after half a second: <http://github.com/paulbaumgart/git-situational- awareness>

<comment><USER10> It would be cool to do the opposite as well, don't start checking the fancy vcs stuff until 1/2 second after the prompt is loaded.

<comment><USER9> Agreed. I don't think Bash allows async function execution, though.

</comment></comment></comment></comment></comment><comment><USER11> I've started using the oh-my-zsh project.

<http://github.com/robbyrussell/oh-my-zsh>

Has all sorts of themes, and most have git status.

</comment><comment><USER12> I love that vcs_info works with more than just git. Having my prompt tell me what VCS I'm under (even knowing the difference between git and git-svn) and what branch I've got checked out helps me mentally switch gears as soon as I cd into a directory.

</comment><comment><USER13> There are a ton of these out there nowadays. A lot of them are OK, but I use: <http://github.com/olivierverdier/zsh-git-prompt>

<comment><USER10> I was just about to post that. I actually made a few patches (pulled by olivier) to make the prompt work better on Mac OSX.</comment></comment>


Russia's Cyberwar on Ukraine Is a Blueprint for What's to Come - <AUTHOR> https://www.wired.com/story/russian-hackers-attack-ukraine/ <comment><USER2> One electricity grid operator used is iPhone to record video of the hack real- time. He watched helplessly (not touching his computer) as someone else moved the cursor about the screen, turning off breakers and causing a regional blackout.

\---

 _The hackers hadn't sent their blackout commands from automated malware, or even a cloned machine as they'd done at Kyivoblenergo. Instead, the intruders had exploited the company's IT helpdesk tool to take direct control of the mouse movements of the stations' operators. They'd locked the operators out of their own user interface. And before their eyes, phantom hands had clicked through dozens of breakers—each serving power to a different swath of the region—and one by one by one, turned them cold._

\---

It doesn't take a careful eye to notice the computer involved appears to be running Windows XP.

<comment><USER3> I recently graduated from Kharkov radio-electronics university, and there, everywhere I had been, believe it or not, all computers had pirate versions of Windows XP and 7 with the updates turned off, though Microsoft generously allows to update even the pirate versions. And I'm sure in most governmental institutions the situation is the same. The most astonishing thing, is that officially these Windows versions are licensed, with proper appropriations from the budget.

Honestly speaking, I'm sure in Russia situation is very similar.

</comment></comment><comment><USER3> what a bullshit. I read to "as popular support in the country has pulled toward NATO and the European Union" and stopped. The supporters of the opposite politics actually have been silenced with artillery and secret police. I'm a ukrainian citizen from Kharkov</comment>


Google Maps API gets usage limits - <AUTHOR> http://googlegeodevelopers.blogspot.com/2011/10/introduction-of-usage-limits-to-maps.html

<comment><USER2> Could somebody explain this more simply?

As I understand it, the site had no usage quota, it was the end user (ultimately the browser making the map API request). The end user had a limit but as this was in the hundreds or thousands (can't recall) it was not real concern for your average end user.

Is this what's changing? The site is now accountable for request quota?

<comment><USER3> My understanding is that the site was always responsible for the usage quota. The calls made (even on the client side) technically is made by the website, so the limit applies to the website. If requests come from the end user and not the site (as you mention), very few people would hit that limit and it would not be a concern.

</comment></comment><comment><USER4> Weird. Is Google "really" interested in (aggressively) monetizing their mapping API (like MSFT, that has each department responsible for their own profitability)?

Or, is this a longer term business strategy? Put up public pricing that allows them to go back to partners and say "here's the new price -- yes it's high, but it's the same for everyone"?

<comment><USER5> I'd say it's not so much a play to monetize their mapping API so much as it is a way to _not_ have everyone in the world sitting on their shoulders for free. Free is the operative word there. Free is a funny thing. It creates artificial demand. I'll give an example.

I used to do independent consulting, and in the course of consulting, recommended Google Apps for email hosting, even if the client wasn't going to use Google Docs or any of the other Google Apps services. It was the best free option for email hosting around. But the fact that it was free created some problems.

Most of the clients I transitioned did so at a time when mail hosts put limits on the number of mailboxes you could set up. A strange concept in today's world, but that was the status quo at the time. Clients would provide mailboxes for users and for general purpose correspondence, but they were reasonable. Once they figured out that mailboxes were free and unlimited on Google Apps (once upon a time), they'd go crazy. Soon, mailbox counts ballooned to 50 or 100 mailboxes for organizations with 15 users or less.

By making their APIs free, Google creates artificial demand, which raises their costs. It's wise to implement reasonable limits.

<comment><USER4> Good point regarding artificial demand.

My surprise at the announcement has also partly/mostly to do with the actual pricing, which kicks in pretty fast (25k free map loads daily). It seems like a lot of small-to-medium, non-profit sites would fit into that. One example amongst many, many others: <http://www.housingmaps.com/>

</comment></comment></comment><comment><USER4> Other discussions on HN: <http://news.ycombinator.com/item?id=3163509> and <http://news.ycombinator.com/item?id=3162352>

</comment><comment><USER6> Ouch. The pricing for >25k/day maps is "contact sales".

<comment><USER7> More detailed pricing information is available here: <http://code.google.com/apis/maps/faq.html#tos_pricing>

<comment><USER6> Awesome, thanks. I looked all over that Premium site and didn't see it.</comment></comment></comment>


Chat Room In 10 Lines of JavaScript - <AUTHOR> http://www.pubnub.com/blog/build-real-time-web-apps-easy

<comment><USER2> I love all the stuff coming out in the Javascript world lately, especially things making comet-style coding easier. That said, seeing last week's chatroom in 15 loc and this week's chatroom in 10 lines kinda reminds me of the "5 minute abs" infomercials. I wonder when the first Perl-style one-liner chatroom will come out? :)

In seriousness, I'd love to see a comparison between this and now.js and some of the others.

<comment><USER3> > I wonder when the first Perl-style one-liner chatroom will come out?

Does "<iframe src='[http://www.pubnub.com/blog/build-real-time-web-apps- easy>...](http://www.pubnub.com/blog/build-real-time-web-apps-easy>) count?

</comment></comment><comment><USER4> 10 lines of javascript..so long as you include these other several hundred lines from a library.

It's cool that you can work this way with the PubNub library--but on the web, where all of the code needed actually has to be downloaded by the client, it's completely disingenuous.

<comment><USER2> Not completely. It does save me from writing the other hundreds of lines, which is more what they mean than a chatroom in 10 loc total.

Anything that staves the onset of carpal tunnel for us hackers a little longer is a good deal to me :)

<comment><USER4> As I stated, I think it's great that you can use the library to help you do this; but the truth is, to use this chat program, clients have to download and execute far more than 10 lines of code.

</comment></comment></comment><comment><USER5> You don't escape html entities, you can easily have fun inverting text with the mirroring character

</comment><comment><USER6> @lux ...curious...do you have a link to last weeks 'chat room n 15 loc'?

<comment><USER2> I believe it was for these guys:

<http://nowjs.com/></comment></comment>