By hard-coded, I just meant set to that time year-round rather than auto-adjusted to meet a physical geographical time. It’s not “select a place to keep time to” (e.g. London), it’s “select a time zone” and as of now, it never automatically changes unless somebody is going to change the way it’s set up. And UTC vs GMT is splitting hairs: yes, it’s the same physical time zone and just the “branding” of it, which is irrelevant when we are talking about systems code almost nobody will ever see.
Yes it is, but that’s how traditional banks do it. I was referring to traditional banks as a comparison. Effectively, to do it that way would be the way to do it if you didn’t want to make any system changes. So the “simplest” adjustment to the tech-stack, although actually a lot of manual work.
They could clearly do it all at once in one second, co-ordinated across the bank, if they wanted. They could also code the change into their systems so it happened automatically, I’m sure. Even if they didn’t want to do that, my point really was alluding to the fact that even manually doing it all is only twice a year, probably covering 12 hours maximum downtime across the year over two nights: the impact of that downtime is likely minimal to most customers who will be asleep, but the impact of having the “wrong time” for six months every year is far-reaching and significant. And the 12 hours downtime is the worst-case scenario of manually forcing the change as traditional banks do. Monzo could do it in a much better way, I’m sure.
There has to be one time across the bank’s systems, but not necessarily the same all year round. @N26throwaway’s issue was actually caused by a single “reference time” being used. If he had done the same thing three weeks ago, he wouldn’t have been charged. Only now we are on British Summer Time, and Monzo is effectively not as it’s reference time is fixed, so midnight for a common person is 11pm “for Monzo”. That’s just wrong. I’m questioning the whole idea of a single reference time. Time used by Monzo’s systems should match what real people consider the time to be. For example, if the clock on the BBC News channel was wrong half the year and the answer given was “it’s in UTC, it’s the BBC’s reference time” everybody would think that was mad! This case is no different.
Time has to be consistently matching, obviously, across all the bank’s systems. That’s the single correct time, at any one moment. There’s no reason why it can’t ever be changed. It could, in fact, be changed easily twice a year to match real time. All other banks manage it and their systems are far more of a mess than Monzo’s, so it should not be impossible to do.
They need to change the reference/server time to avoid these issues though. The server time is the system’s idea of the “correct” time in calculating fees, daily allowances, etc.
I’m not drawing a technical parallel, that misses the point; I’m only drawing a parallel between how different banks treat time as a concept. This wouldn’t have happened at a traditional bank because traditional banks keep the “real time” in the UK as their reference time all the time. Monzo should too. As you say, I’m sure that would be achievable for Monzo without multi-hour downtime and manual overrides of time records in their systems. But, to emphasise the point, there is a reason why the other banks bother to do all that twice a year - ensuring an accurate time is very important!
There’s a danger in assuming just because Monzo has a micro-services architecture, the way it’s set up must be better, self-evidently. @N26throwaway has just experienced an issue directly caused by this oddity which has caused (minor) financial loss. It could equally have caused significant loss. That’s not better for him however you look at it.
Yes, I assume it does too.
But it’s probably just a separate instance of Monzo’s tech stack hard-coded to UTC-5, which is East Coast time not including summer time adjustment, so I suspect the same issue would be possible there.
Good point, but I personally suspect it’s that each component is set to time zone UTC and that’s it: to go back and unlock it, as you say, may be a very big job. They could either change all their code to point to a new reference time (and change the reference time when clocks change) or, what I suspect big traditional banks do, let systems think you are on GMT or UTC all the time but simply “force” the change by manually overriding the time to create a change when required.
Was just trying to illustrate the general concept - apply charge at 1am when that’s 12 midnight for UK customer - without going in to the full detail of carefully setting dates and accounting for exceptions.
. If anyone made a change to fix the overall time in the system it would bug that line of code out, plus hard coding specific dates 
. As I say hopefully the standards are a touch higher than adding specific rules like this into individual features.