Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> but the customer service is incredible. If it breaks or doesn’t do something you need, the company is willing to fix it or build it.

At $20k+ per annum cost I wouldn't expect anything less. That said we Europeans have been asking for non American date format support for years but it's a won't fix. So I guess the fee still isn't large enough.

A big complaint I have is why can't I keep the data I download off the terminal for an exchange if I'm already paying the exchange fees in addition to bloomberg's annual fee? It's like renting data. Also it makes it difficult to switch to a competing product.

Another mild annoyance is the left field approach their reps have about the tech that is visible when they make their regular visits to your office. Your company might have invested in developing data screens ,(outside of Bloomberg) and some months later those views mysteriously become available as new functionality for all users. It's even worse if you use their API; eg, you might write a private back-testing indicator specific to your market and within a day or two it appears in their public indicator list.



> At $20k+ per annum cost I wouldn't expect anything less

You’d be surprised. Contrasting e.g. PitchBook, Reuter’s and Bloomberg, the latter’s <HELP><HELP> is like magic. They’ll happily step into your shoes and turn around quality work product for you. And on more than one occasion, they used feedback to add features to a screen.


I've always found that HELP HELP is super fast and efficient for power user advice like "how do I price this type of bond" but utterly worthless for "how do I use this API" type queries.

It feels like there's some heavy gatekeeping that stops people from accessing the devs.


I interviewed to be one of those customer support agents many moons ago and I think the reason is that the agents at the other end of HELP HELP aren't technical themselves. When I was looking into it they would hire any fresh college grad who seemed smart enough to learn the product features. Programming skills were explicitly not required so I'm not surprised that they couldn't help with programming questions.


I am one of the devs at Bloomberg, and I'm quite glad not to be accessed by random customers ;-)


the market data fees are crazy. But it might be either bloombergs agreement with the exchange or your agreement with BBG. If you have direct agreements with the exchanges normally you can do as you need with the data following that agreement. Anyway B-PIPE is their main market data offering and is super expensive (3-5 terminals?)

They are very good having the reps take your ideas and sell them to you. I don't like how the reps swarm you and try to sit all day next to you watching what you are doing.


Also I have live tick by tick fx, interest rates and bond prices in the bloomberg terminal. But I have to go to yahoo finance for live equity prices...


Surely not? You can decide what exchanges you want to pay for.

FICC prices are also not quite that easy, there's a number there but what it means varies according to how you're configured. Things like the closing time and what sources go into the rate make a difference.

I spent a lot of time talking to bbg about what all the settings were.


As an example of what exchanges charge for licensing the data (not including a feed for the data, just a licence to use it) I have to pay £18k/year just for a London Stock Exchange licence. Then I have to pay for the feed.

Charging for access to the data feed seems fair enough, but licensing the data? For a company that has a monopoly over what I consider public data £18k is outrageous.


yeah you can pay for some additional feeds. But my point is that the base terminal that costs $20,000 a year doesn't come with the sort of live equity feeds that you find for free on google or yahoo finance.


The exchanges make huge amounts of money off live price feeds. Wrongly IMO, but that's another tangent.

Basically there's no way they would let a player like Bloomberg forward that kind of data to their users without getting paid a lot. In fact if you work in HFT you might have heard of something called a non-display fee which is a kind of ransom money they make that kind of firm pay.

Consumers like the ones who look at finance websites are probably not people they care to market to. Hence someone like investing.com can cut a deal to show live prices. They're not depth and pretty slow in any case.

But basically Bloomberg do not own the equity prices, the exchanges do.


I've been waiting 15 years for litigation in this arena. If prices, like player statistics from an NHL game, are historical facts which can not be copyrighted, why don't we have better and cheaper public market data API's by now? How have the exchanges been able to maintain a stranglehold over distribution of historical facts?


Their regulator(s) support them selling it. And they can easily cut anyone off for re-distributing it (in addition to any legal remedy they may attempt).


> And they can easily cut anyone off for re-distributing it (in addition to any legal remedy they may attempt).

AFAIK that's what grsecurity does. They distribute linux patches, which aren't copyrightable because they're GPL. To prevent anyone from distributing their patches openly (and putting them out of business), they have a clause in their contracts saying that if you distribute their patches, they'll terminate your subscription.


Are the feeds on Yahoo and Google actually up to date? I was pretty sure Google was on a long (like >1m) delay.


Investing.com is live. But also most (all?) of retail brokerages are live.


Looks like my retail brokerage didn’t get the memo. I get 15 minutes delayed data unless I subscribe to the exchange AND OPRA on top of my trading and holding fee.


European here, American date format is better.


American here. It sucks. ISO dates are the best solution.


I mean ISO. It's lexicographically ordered. And gets more detailed / fine-grained reading left to right. (Year-month-day). I like those features.


American here, and ISO is better than the common American format, though US military date style is also better than the more common American format, and maybe better than ISO for some uses.


I mean ISO. It's lexicographically ordered. And gets more detailed / fine-grained reading left to right. (Year-month-day). I like those features.


> US military date style

That's basically the European format.


Different European here, the american date format makes absolutely no sense to me and I've lived in america for the last 6 years.


I mean ISO. It's lexicographically ordered. And gets more detailed / fine-grained reading left to right. (Year-month-day). I like those features.


I mean ISO. It's lexicographically ordered. And gets more detailed / fine-grained reading left to right. (Year-month-day). I like those features.


In everyday business, when dealing with dates, the month is usually what you care about most, followed by the day, and then the year (which is often redundant or implicit).

Thus, month/date/years is more "ergonomic" or "user friendly," if one is equally used to either format.

A similar example is time. The hour is usually what you care about most, followed by the minutes, with seconds most often being irrelevant. Fortunately, that's how everyone writes time.


In everyday business, I would generally start with the day and then follow with the month if it's relevant (often it's not, if talking about a date in the near future), and finally by year if needed. I can't imagine when I'd start with the month, really, but that might be because in Finnish you'd almost always say and write dates with the day first.

As far as date formats go, apart from the ISO format, "21 Jul 2020" is definitely my favorite and always unambiguous. The only downside is that it's language dependent.


I mean ISO. It's lexicographically ordered. And gets more detailed / fine-grained reading left to right. (Year-month-day). I like those features.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: