ISO8601 is wasted

Why did we even bother?

Why create ISO8601?

A new API, new this year, as an industry standard, has JSON fields like this
"nextAccessTime": "2023-May-18 04:43:00+0000 UTC"

I mean, pick a lane, why "+0000" and "UTC"?

Why "YYYY-MName-DD" FFS, that is not *any* standard in RFC or ISO?!

I just don't know how they could have come up with that in any sane way.

The xkcd "cat" format would be saner!

(FYI, it is TOTSCO)



There are lots of ways to debug stuff, but at the end of the day it is all a bit of a detective story.

Looking for clues, testing an hypothesis, narrowing down the possible causes step by step.

It is even more, shall we say, "fun", when it is not definitely a software or definitely a hardware issue. Well, to be honest, we know it is hardware related, but it could be hardware because the software has set something up wrong, or is doing something wrong, maybe. Really a processor hang should not be something software can ever do no matter how hard it tries, in my opinion, but in a complicated system with complicated memory management hardware, it is possible that a hang can be the side effect of something wrong in software.

I was going to say that "when I was a kid, software could never cause a hardware hang", but I am reminded not only of the notorious "Halt and Catch Fire" accidental processor operation, but that one could walk in to a Tandy store and type the right POKE command on one of the earliest Apple machines and turn it in to toast, apparently. So maybe there has always been this risk.

The latest step in the "watching paint dry" process of trying to diagnose the small issue we have with the new FireBricks is underway now. It has been a long journey, and it is too soon to say it is over. It will be an awesome blog when it is over, honest.

One of the dangers with software is the classic Heisenbug: a bug that moves or goes away when you change something. We are chasing something which, by our best guess, is related to some aspect of memory access. This means that even the smallest change to software can have an impact. Make the code one byte shorter and you move all the interactions with cache lines when running code, and change the timing of everything as a result. When chasing a big like this, you cannot rule out those being an issue. So a change of one thing may result is a change in behaviour somewhere else. We have seem a lot of red herrings like this already.

The latest test is unusual for us. It is a change to an auxiliary processor that controls a specific clock signal to the processor before the code even starts to run. One we don't currently need. And we are removing anything we don't need, no matter how unlikely it is to be the cause.

What is fun is that this means we have not changed a single byte of the main code we are running.

If this works, and only time will tell, we can be really quite sure it is not some side effect of simply recompiling the code. It pretty much has to be the one thing we really did change.

Being able to test something so specific by a software change is quite unusual.

Data packages

Our old SIP2SIM was "pay as you go", and the new one has monthly capped data packages.

To be honest, people have asked for this for a long time, but as ONSIM are selling us data packages, it makes sense to do the same, at least for now. Monthly 2GB, 4GB, 10GB, 20GB, 40GB. It is also more sanely priced than before.

But, of course, it is not simple.

So, for a start, adding data to a non data SIM, mid month, is a pro-rata data for rest of month at a pro-rata price. So far so good.

But what of increase of data package mid month. My thought on this (and it depends on ONSIM), is we update to new monthly, pro-rata if data started mid month, to new package, and the same for price. Mostly it will be an increase for whole month to new monthly rate and the difference in monthly price.

But what of decrease? Well, I guess, maybe, the same logic could apply, but only if you have used less than you would now have for the month. My thought it no, lowering the package is setting a new lower level for next month. This is far simpler, and no billing implication and no change to this month.

Of course if you then increase again, we have to allow for the fact that this month you are on a higher package than you will be next month, and only consider it an increase relative to that.

This is never simple, is it.

Hopefully we have something soon, sorry for the delay, waiting on ONSIM to do the necessary APIs for us.


07700 900461

This is the mobile number for Dr.Who.

The number is part of OFCOMs allocation for theatrical numbers. So not a valid UK number.

I could fake that number for calls or texts if I wanted to as I am a telco, but doing so would cause problems, as it would be a against OFCOM rules (General conditions), so obviously I would not do that. And obviously doing so for any fraudulent reason would be illegal.

I think people know we try to "do things right" anyway.

But I had a unique opportunity, I thought. Our new SIP2SIM service allows a mobile number to be set on the SIM. This is mainly to allow clean and easy defaults to use our service for calls and texts to and from the mobile.

But is also allows iMessage.  For iMessage to work there is a "behind the scenes" SMS each way to Apple, and the carrier we are using handle that internally. Makes sense.

This works even for numbers that do not normally get SMS, like our landline numbers. This is great. We are actually working on getting more SMS on landline numbers now, but this cuts out the middle man and allows it to work. All of our actual numbers can be valid as iMessage using our SIMs. Yay!

Basically we can make iMessage work with any of our actual numbers.

So nice, but in theory we could "hijack" any numbers for iMessage. This is not such a shock, honestly, the way mobile networks work is so open "within the telcos" to be scary. We are very careful to follow the rules, and do it right. A lot of telcos could "hijack" almost any number at SMS level. Don't be shocked, really, SMS is crap for security, honest.

But let's play by the rules, what if I was to "hijack" the number for Dr.Who? 07700 900461

Would that be legal?

Well, it is not someone's actual number.

And it is not fraud.

And we would not use for CLI for calls or actual SMS. So not covered by OFCOM.

I suspect it would be "legal", just.

So yes, to wind up my brother, I tried.

 "error":"Failed to provision user on network - please contact support"

Bugger, such a shame.

I mean, it would have been funny, and that was it, not fraud, not illegal, but sadly also not possible.


Adults must show ID to use social media

The stories in the press are "Children must show ID to use social media".

This is totally misleading.

"Passes please": All adults must show ID to use social media.

That is the real story here!

Children (under 13) are actually the ones that won't have to show ID as doing so won't help them. But for this to work, everyone will have to show ID to use social media!

P.S. This is my proposed email to ICO, if this ends up covering Mastodon.

Dear ICO,

I understand that under new rules, as the operator of a social media platform, I have to advise you how I check the age of my user. I have used two methods.

1. Looking in the mirror and seeing I look well over 18.

2. For around 55 years I have meticulously counted the number of birthdays I have had, that number being 60, which is more than 18. I did rely on my parents to confirm the first few.

I trust you find this meets the requirements.




As anyone reading my blog will know, I got COVID (on a cruise) last September. This was way worse than the first time a year or so before.

The infection at the time was bad, scary fever, especially on a cruise, but within a few days (and thankfully on dry land) I then had a stroke. I can't help feeling it was related.

The stroke was mild in many ways, mostly dysarthria (can't speak properly) and that cleared up maybe 90% in a few hours but not totally. Being in hospital was a pain, and I am now on blood thinners (forever).

But there is more, some subtle. Some may be COVID, some may be the stroke.

  • A general tiredness
  • Just can't get things done - just don't want to get things done
  • Not quite "myself" in coding stuff and doing work generally - can't think straight
  • I notice that when I walk, my right arm is rigid until I think about it!
  • My typing is worse, a lot worse

The real clue is some of these have improved, my typing is still hard work but better. I am finally getting in to the swing of working and coding. Not my old self, but way more than I was.

I am posting now as I have had a weekend working, and coding, and doing well, and it feels such a change. Such a relief! Almost back to my old self, which is great!

Oddly my right arm being rigid when walking is still a thing. Not like I can't move it. When walking my left arm swings and my right arm does not - until I think about it. Very weird.

My typing is not yet right, and I know it was not perfect before, but I see how bad it is still. I have to think more, and I have to check a lot more than I used to. But I feel it is improving.

It is weird trying to debug the way my own mind and body is working.


Is it spring yet?

This is more like it, but is only one day!

Most of our import (and today it is likely all of our import) was 2am to 5am at 14.71p.

Most export was during the day at 15.08p.

A lot of export, around 15kWh (54MJ) was 4pm to 7pm (actually 5:30pm to 7pm so we save some for evening) at 24.93p

Doing the sums I think...

  • Import 34.1kWh (122.8MJ), assume 14.71p, £5.02
  • Export sunshine, 26.7kWh (96.1MJ) at 15.08p, £4.02
  • Export battery, 15kWh (54MJ) at 24.93p, £3.74

Total electricity bill (excluding standing charge) -£2.74, and that left some in the battery still.

Without solar and battery? House used 31.4kWh (113MJ) and would have been mostly 24.51p, so £7.70.

If only every day was like this.

ISO8601 is wasted

Why did we even bother? Why create ISO8601? A new API, new this year, as an industry standard, has JSON fields like this "nextAccessTim...