If you’re writing dates this way:
Jan 12th 2010 – you’re living in the past, and you’re doing it wrong.
12/01/2010 – you’re American and you’re doing it wrong.
1263298212 – you’re a machine, why are you reading my blog?
2010-01-12 – you’re ISO 8601 compliant ✅.

ISO 8601 is the standard for date writing. There are several benefits for using this standard for date writing, so here’s a list.

It’s Sortable

Yep. Dates written in ISO 8601 are sortable by a standard string sort algorithm. No natural sort required.

It’s Logical

From left to right, it’s written in Most-Significant to Least-Significant order.

2010 is the year, changing this by one means you’re a whole year off, so it’s the most significant part.
01 is the month, changing this by one means you’re one month off, so it’s less significant.
12 is the day, changing this by one means you’re only a day off, so it’s the least significant.

Of course the ISO 8601 standard includes time formats as well, and you can go read about those in your own time.

It’s Unambiguous

We’re not all American. If someone writes a date in the format 12-01-2010, we don’t know whether it’s referring to the 12th of Jan, or the 1st of December.

With 2010-01-12, everyone knows what we’re talking about. Because nobody ever writes dates in YYYY-DD-MM format – that would just be inane.

It Uses Safe Separators

If you use a slash / to separate the date fields, you need to escape those if you want to use them in a filename, or in a URL.

Whereas if you use the dash – character, there’s no escaping required.

It’s Language Agnostic

If you use Month names in the date, such as ‘Jan’, ‘Feb’, etc. Then the dates should be translated when you’re using them on i18n‘d sites.

Because different languages have different names for the months of the year. Duh.

But if you use ISO 8601, there’s no need for the translation, because numbers don’t usually need translating.

Huzzah! Now go fix your broken date output formats. 👋

Everyone loves a good safe. Ok, maybe every security person loves a good safe. Ok maybe it’s just me.

The problem with safes, is trust. You just don’t know if whoever made it, or whoever you bought it from, has a spare key, or has modified the hardware to grant them easy access at a later date.

To quote the late George Carlin, “these are the things I think about when I’m sitting alone at home and the TV is broken”.

I have a safe, it’s a very nice safe. I deliberately got an electronic one with no backup key. So if my house is doused with electromagnetic radiation, I might have some problems getting stuff out of it, but to be honest, I think that’s the least of my problems at that point.

I decided I wanted to re-engineer the electronic locking mechanism, so I could be 100% sure that any manufacturer errors in either the hardware or the firmware wouldn’t affect me. And I trust my own source code than code written by anyone else, unless that code is open source and has been heavily peer-reviewed.

So, I decided I wanted to use an Arduino at this point, largely because the only microcontrollers I have are Arduinos and Raspberry Pis, and because a Raspberry Pi would be overkill here, and also because I have a number of Arduinos knocking about doing not a lot, I decided to use an Arduino.

An Arduino Nano, sporting an Atmel ATmega168 processor, to be precise.

So I took the safe door off (really easily in fact, which is a nice feature of this safe) and I removed the existing I/O parts, including the keypad. I’ve had a vandal-resistant keypad that I got many years ago really cheaply that I’ve been looking to use for ages.

I soldered on the wires, fed them through the wire-hole, then marked out where the keypad would be mounted to the safe, and drilled some holes so it could be riveted in place. Didn’t want to use bolts as this is a fire safe, which means it is very thick, being largely filled with insulation. Rivets are a clean solution here.

Passed the wires through, and stuck a couple of breadboards to the inside of the safe using sticky pads. Incidentally, the breadboards came with sticky-pad backings, but they were a few years old and had lost all of their sticky, even having been covered up the whole time.

Next step, snip the wires to the solenoid (this provides the locking mechanism, preventing the bolts being withdrawn), strip the wires a little, and plug these in to the breadboard. I guessed the solenoid worked on 5v due to the size of the battery pack in the safe, but I also needed to measure the current drawn by the solenoid, so I would know what kind of power is required. Arduino digital outputs have a max draw of 40ma at 5v, so I’d guessed the solenoid would need to be powered more directly from the supply. Turns out the solenoid draws about 500ma at 5v, which is a happy coincidence for my plan to use a USB power supply.

Because I didn’t want to put batteries on the front or back of the safe, I instead stuck a micro-usb adapter on the front, from a pack of them I bought a while ago. I also fed the wires for this through the wire-hole.

After I’d put some wiring in, I decided to add a beeper, this my alternative to having a visual output; I needed some user feedback to indicate the safe electronics are alive and keypresses are being registered.
It also means I can play a bad noise when the code is wrong, and a good noise when it isn’t. I added a tiny capacitor to the speaker circuit just to take the tiniest corner-edge off the square-wave speaker noise, but is generally not required.

Next step, set up a transistor ‘darlington pair’ to activate the solenoid on demand.

After that, the code.

Keeping it simple, I decided not to program in a ‘pin change’ option, or ‘timeout’ for multiple failed attempts, or any other wizardry. The reason being, that I can just set any pin code I like in my source code. The pin in the source code on GitHub is not the one I programmed my safe with. #notAnIdiot.

With this code, I can easily set any pin code between zero and 24 digits, using chars 0-9 A-D. Because I don’t like arbitrary restrictions.

Pressing # submits the pin you just entered, and * resets the input. That’s it.

It also makes a beep when you press a button, it plays an angry sound when you get the pin wrong, and plays a nice C-Scale when it is unlocked.

You may also notice the small bungee cord at the bottom of the image, which is another little customisation, to prevent the bolt being left in the unlocked position. No accidents. Job done.

Source code available here.