Converting UNIX dates to a readable format on Mac

I tend to run into UNIX dates — large numbers representing points in time as seconds since the first second of 1970, something like 1500000000 for 2017-07-14 05:40:00 — all the time in my work, dealing with servers, web APIs, etc.

Here's how to make them readable on a Mac. All text below assumes macOS 10.13.


The most straightforward solution is probably to open and run date:

# Outputs Fri Jul 14 05:40:00 EEST 2017
date -r 1500000000

# Outputs 2017-07-14 05:40:00
date -r 1500000000 +'%F %T'

Services: shell + AppleScript

Command line isn't your only option. macOS has a Services menu where you can add all sorts of useful things that operate on your selection:

Services menu screenshot

You can create a Service menu item pretty easily from the date invocation above.

  1. Launch Automator
  2. Create a new document. Select Service when Automator prompts for a type.
  3. Add "Run Shell Script" action. Select /bin/sh as the shell. Set the following as the content:

    sh xargs -I INPUT date -r INPUT +'%F %T'

  4. Add a "Run AppleScript" action. Set the following as the content:

    applescript on run {input, parameters} tell me to display dialog input with title "Date" buttons "OK" return input end run 5. Save the document, select text anywhere, select the \<Program Name> → Services → \<Your Automator document name> menu item, and you'll get a dialog box with the converted date.

Services: Javascript

Starting a shell, invoking (with no input validation) a couple of command line tools, then piping that to AppleScript is not very satisfactory.

You might be able to eliminate the first step and do all of it in AppleScript. But that would mean writing more AppleScript. I prefer to avoid that.

macOS offers another option: JavaScript for Automation, also known as JXA. Not exactly the greatest of languages either, but it's not as read only as AppleScript. And while its standard library is not great, it can handle dates. So we can reduce our Automator script to one action and improve our input validation at the same time.

  1. Start by again creating a new service in Automator.
  2. Add a "Run JavaScript" action. Set the following as content:

    ```javascript function run(input, parameters) { const app = Application.currentApplication(); app.includeStandardAdditions = true;

    const inputInt = parseInt(input);
    if (isNaN(inputInt)) {
        app.displayAlert("Not an integer: " + input);
        return input;
    const d = new Date(inputInt * 1000);
    app.displayDialog(d.toISOString(), {
        withTitle: "Date",
        buttons: ["Close"],
        defaultButton: "Close",
    return input;

    } ```

  3. Now again save the document. The new service is available in the Services menu.

Here's the window you get:

Date dialog screenshot

The output from toISOString isn't quite as nice as %F %T from date, but if you're used to ISO dates, it's not bad. Making it prettier is left as an exercise to the reader. Start with Mozilla's documentation for Date.

There you have it! Maybe some day we can use Swift and the Foundation libraries for automation, but meanwhile I can live with the JS solution.

Article page

Netstrings for Swift

I published another small Swift library: swift-netstring implements reader and writer for D. J. Bernstein's Netstrings format in Swift.

Netstrings is a specification for length-prefixed and delimited byte strings, useful mostly as a low-level building block for network protocols. With swift-netsring you can parse incoming data from a socket or some other stream by wrapping the stream in a simple closure that reads bytes synchronously. Or you can feed it an array of bytes.

You can find examples in the repo in the README, in a Swift playground and in tests. There's also API documentation (a big thank you to Jesse Squires for an excellent guide for setting up docs on GitHub pages for a Swift project.)

Article page

Flue: Fluent API for value extraction and conversion for Swift

Flue is a Swift (3.0, as of this writing) library for extracting, validating and converting values from user input. It tries to do this with a fluent interface:


It can output readable help and error messages from your conversions. See the README for details.


Article page

Talking to servers: WebSockets

This is a sort of follow-up post to ZeroMQ, iOS and Python from a year ago. I again wrote a test app and server. Of the earlier components, iOS stayed, but ZeroMQ I replaced with WebSockets and the server is this time written in Clojure.

Idea of the exercise is the same as last time: two-way communication between an iOS client and server over a persistent connection. WebSockets is a more mainstream technology than ZeroMQ with a wide variety of servers available, even if it is a young spec and not quite everything has stabilized yet.

On the iOS side there's two options, short of writing the protocol implementation yourself: some kind of horrible Javascript-UIWebView bridge and Square's SocketRocket. I went for SocketRocket. It's available from CocoaPods and at least in this brief test worked fine.

Last time I was planning on doing the server in Clojure but ran out of patience. This time the technology stack was easier. I pretty much followed Jay Fields' example with just a few changes here and there and had a server running in no time.

The system doesn't do anything fancy, or do it particularly beautifully: the app waits for a button tap, sends a number wrapped in JSON to the server, the server increments it and sends it back.

The code is on BitBucket as always. Enjoy.

Article page

NSStringinfying enums from AppCode

I added a --text option to nsstringfromenumgen so it can be used with JetBrains' excellent Objective-C IDE, AppCode. AppCode doesn't integrate with OS X services, but you can configure nsstringfromenumgen as an "External Tool" and provide the selected text as a parameter. There's still an extra copy & paste step not needed with Xcode and Services, but it's not too bad.

Article page

NSStringinfying enums

Making sense of enum values in C is too difficult. Usually sooner rather than later while debugging you need to see what's inside an enum value, but C provides no introspection tools. You just get an integer value, no mapping to the original symbolic name. That's why every enum should be accompanied by a stringifying function, but that requires manual labor. Few programmers are happy to write those functions and fewer are going to update them. Automation to the rescue.

I'm working in the context of Objective-C, and so is Wolf Rentzsch, who recently blogged his script for generating NSStringFromEnumName functions. I have used a very similar solution for a long time, and I expect so have many others.

But you don't have to be jwz to doubt the wisdom of parsing C with a bunch of ad hoc regexps. I was always unhappy with it and knew there were various not-so-corner cases I wasn't handling properly. Using a real C parser seemed like the right thing to do, but it hasn't really been feasible until pretty recently, after the advent of libclang.

So, here it is, using Python and clang, my most recent take on NSStringFromEnum. It might not be any better for being based on libclang, but it's different.

Article page