411–420 of 456 posts
Earlier quoted context omitted.
Maybe he should get Stephen Colbert's second-by-second day planner.
It's dumb you got downvoted for telling a joke, geez
Earlier quoted context omitted.
Think of all the time that could be better appropriated than on fintech in general. Seems like such a waste of resources siccing a bunch of computers against each other in a zero sum game of stock arbitrage. I will admit some of the stuff tech comes out of it is cool on its own at least.
Eh. I see the downsides of a lot of that HFT stuff, but there are upsides too. Yes a lot of it is zero sum, but not all of it is. Lowering spreads between currencies, say, does materially help non-finance actors. There are other areas of the stock market that are useful too. Ingesting financials and other non-manipulated data to better reflect a company's true worth at any time helps, for example, employee option hol…
Yet when I go somewhere with no liquidity and a huge spread like a crypto exchange, a deeply unpopular corner of the stock derivatives market, or a Craigslist used stuff category, the wide spread is just a mild inconvenience at worst. You get to choose between waiting for a better deal and taking a worse deal immediately
A tight spread just means that somebody is getting rich by taking that choice away from me and everyone else on the exchange. It's not the most nefarious thing in the world, but it's not particularly helpful or altruistic either.
I trust we will also be getting rid of leap years: that whole pausing the calendar for a day thing is very confusing. Oh wait, that's not how it works. And neither is it how leap seconds work.
Those are very different scenarios, they aren't equivalent. Leap years have to do directly with the sun, what day and time the equinoxes happen every year and the like. This time noticeably drifts every year, even every day, computers or not. These leap seconds and what not have to do with very sensitive instruments measuring time very precisely. These time measures are entirely about machines.
Only the madness of "smearing seconds" and other workarounds for broken software with incorrect calendar implementations makes them seem different.
Currently software has to be built to accommodate leap seconds. They happen frequently enough that you'll find out within a few years whether your software breaks when time suddenly skips forward or backward. If we kick the can down the road such that eventually we'll need to add a leap minute, we're going to end up with software that was never written to expect time to change in such a way, hasn't had a real world t…
clocks get used for two distinct purposes, often at odds: - the measurement of durations. - the presentation of some timestamp in a way that the reader has some intuition for. that first purpose won’t be hurt by not tracking leap seconds. actually, a lot of applications will probably more accurately measure durations by eliminating leap seconds. if leap seconds (or minutes) really are of critical importance, we’ll re…
1) Seconds since 00:00:00UTC 1.1.1970. This value increases by 1 each atomic second and never goes forward/back. Call this Universal Monotonic Time.
2) The difference between when the sun is at its zenith at Greenwich and 12:00 UMT. Call this the Astronomic Drift.
3) The timezone - offset from Greenwich that makes the local clock sync up with astronomic time and also contains a DST offset if that location observes DST at that date.
By adding up 1) + 2) + 3) you end up with the "human time" at a given location at a given date.
A computer system should only ever store 1). Then, it can calculate human time when displaying it to humans.
I'm also a fan of having "local sun time" which would be the time according to the position of the sun in the sky, quantised to 15-minute slices (basically micro-timezones). It would be nice if office hours, school times, &c can be defined based on that, i.e. work starts at 9am local sun time, which will sync up better with people's biological clock and cut down on the yearly stress DST causes.
Hot take… Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TA…
Earlier quoted context omitted.
Eh. I see the downsides of a lot of that HFT stuff, but there are upsides too. Yes a lot of it is zero sum, but not all of it is. Lowering spreads between currencies, say, does materially help non-finance actors. There are other areas of the stock market that are useful too. Ingesting financials and other non-manipulated data to better reflect a company's true worth at any time helps, for example, employee option hol…
Market makers are always talking about "lowering the spread" being this great thing they're doing to make the world a better place Yet when I go somewhere with no liquidity and a huge spread like a crypto exchange, a deeply unpopular corner of the stock derivatives market, or a Craigslist used stuff category, the wide spread is just a mild inconvenience at worst. You get to choose between waiting for a better deal an…
Someone who wants to buy or sell goes to a market in order execute at the best price achievable, and they may be under time pressure.
If the spreads are wider at one place than another, participants will gravitate to the place with the narrower spreads. If there is better liquidity at one place than another, activity will move to that place.
The purpose of being at the market is that you want to trade.
These qualities that you dismiss, "a mild inconvenience at worst", are the essence and measure of a market's effectiveness.
"A tight spread just means that somebody is getting rich by taking that choice away from me and everyone else on the exchange."
No, it is the opposite of that. It is when spreads are wide that there is easy opportunity for getting rich. Consider: it is more lucrative to buy from one person at 10 and sell to another at 20 then to buy from one at 15.01 and selling to another at 15.02.
"You get to choose between waiting for a better deal and taking a worse deal immediately"
That is not the choice. On a good market you get both a competitive price, and you get to deal immediately.
An order that you rest on the book is called a limit order. You can do limit orders on any market, even those where market makers operate. Creating a market that offers limit orders is easy. The more challenging problem is to create a market where people can come and place market orders that get filled immediately
Four years ago, I wated to sell stock to close a deal to buy a house. I didn't want to sit around for hours or days or weeks or forever tweaking limit orders, hoping the market would move in my direction and that the house would stay on the market. I went to market to execute, got my money, and put down the deposit.
If a company goes to a market to offset risk, they typically want the convenience of getting the deal done immediately. If they have to wait weeks to close the deal, the risk might already have past by the time they could get the deal done. Liquid markets with tight spreads get rid of the workflow and loss of time inherent to haggling whilst giving you justified confidence that you are getting a competitive price.
Earlier quoted context omitted.
The interesting thing about DST is that it's not really repeating the hour, if you include the time zone offset in your time stamp. Here, look. Using the time zone for Norway in this example, with the `date` command on macOS. First the last second before DST ended in Norway this year. TZ=Europe/Oslo date -I seconds -jf %s 1667091599 2022-10-30T02:59:59+02:00 Then the second after. TZ=Europe/Oslo date -I seconds -jf %…
The problem is that nobody does it, for example no DB (AFAIK) does it, they all store dates as something like a Unix timestamp. And for a lot of things problems would be solved with +01:00 offset while for others you actually want Europe/Berlin offsets
In 2015 I was working at a "fintech" company and a leap second was announced. It was scheduled for a Wednesday, unlike all others before which had happened on the weekend, when markets were closed. When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours. So I was assig…
Earlier quoted context omitted.
Interesting point. Just like a skater pulling their arms in, snow melting and running to lower ground would make the earth spin faster (and let's add in the extra erosion). Sea levels are rising though (due to both thermal expansion and runoff). Be interesting to estimate the size of the various effects (no doubt I've missed plenty of others) but is it really true that a change in sign of the acceleration of Earth's…
I don’t think that’s right. I would think the effect of melt of glaciers on mountains would be negligible and the effect of the poles melting and sending that water down to the poles would slow down rotation, like an ice skater pushing their arms out.
Earlier quoted context omitted.
Great, here's another. $work had thousands of full custom, dsp-heavy, location measurement hardware devices widely deployed in the field for UTDOA locating cell phones. It used GPS for time reference -- if you know your location, you can get GPS time accurate around the 10's of nanoseconds. GPS also broadcasts a periodic almanac which includes leap second offsets: if you wanted to apply the offset to GPS you could de…
It seems the less likely an event is to occur, the less likely your vendor put work into handling it. This recalls perhaps the biggest mistake in the GPS specification, the 1024-week rollover period. A timespan long enough to be impractical to test without expensive simulator hardware, short enough to be virtually guaranteed to cause problems in long-term installations... and long enough for OEMs to ignore with impun…