Way back in November of 2018, I was sold on the serverless future. And when it comes to Serverless, the best bang for your buck is Firebase. Between a generous free tier and a huge array of services that seamlessly transition to a broader array of GCP offerings, it’s no wonder that so many people use it as the stating point for new projects and companies.

One thing that consistently irritates me, however, is the Firestore UI. As I keep working on side projects that utilize Firebase and Firestore, I’m using the brief periods of respite between them to focus on these grievances.

Today’s issue: dates.

Firestore has 2 supported formats for dates, Javascript Date objects, and Firestore Timestamps. Yup, they not only have a date type, but also a timestamp type. Who made this decision? Why?

Javascript date objects are huge problems, obviously. Presumably your entire company / project won’t just be Javascript, so when it comes to exporting to Big Query or any other place, vanilla JS dates simply won’t work. Timestamps are a little better, but of course that means you have to convert to a date in your client code wherever that’s used, and while easier to export to Big Query, it’s still not actually ideal. I think it’s meant for people who legitimately need the nano-second level precision that it offers, but I don’t know who actually needs this… and if you did, why you’d use something like Firebase.

Anyway, almost everyone I’ve met prefers epoch milliseconds - it’s tried and true, and it just works. Everyone and their mother can convert to and from epoch milliseconds, so why not just use that? It’s what we ended up standardizing around at Skip - but there’s only one problem. It’s not very human readable. Both the date and timestamp types are auto-converted to human-parseable date strings in the Firestore UI.

Well, with this new chrome extension I wrote, that problem is solved.