Matthalp

Column (https://column.com) | ONSITE San Francisco, CA | Full Time | Software Engineers (Backend, Infra, Product, Security) | Forward-deployed Engineers | Solutions Engineers, Payment Ops, Growth, Partnerships & Emerging Markets

Column is building the infrastructure that powers the US dollar globally. We're a software first company, but also own a nationally chartered bank that we've built from the ground up. We're processing trillions of dollars annually, supporting some of the largest and most sophisticated companies out there like Wise, Bilt, Brex, Ramp, Mercury and dozens of others.

We just launched stablecoins, full-stack card issuing, global banking, and multicurrency accounts: https://column.com/launch

Column was founded by William Hockey, who previously started Plaid. We keep an extremely lean and experienced team, and we're looking for ambitious people who want to build incredible software from first principles:

- Software Engineers (Backend, Infra, Product, Security) - Forward-deployed Engineers - Solutions Engineers - Payment Operations (new grad / early career) - Growth - Partnerships - Emerging Markets

Profitable and owned by employees and founders.

Apply here: https://column.com/careers

I am one of the engineers who built this. Column is an OCC-chartered bank with its own in-house built banking core, so the processor runs on the same core as our ledger and payment rails.

We have direct integrations with Visa and Mastercard. It supports credit, debit, charge, fleet, prepaid, and stablecoin-backed programs, and what you'd expect from a mature issuer processor out of the gate: 3DS, digital wallets, Level 3 data, disputes, spend controls, and card manufacturer integrations.

Happy to answer questions!

Hi @rsclient! Thank you for taking the time to read the post and providing the feedback. I've gone ahead and updated the post and library code based on it.

> the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.

Yes, that is a good catch. The variables were mis-named and should have been "eastern" (ET) and "pacific" (PT) and not EST/PST given that "America/New_York" and America/Los_Angeles" were the reference timezone. If someone just wants EST or PST they would need to create a timezone bound to just that. The library supports statically typing either and would prevent EST/ET or PST/PT from being used interchangeably.

> Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.

Yes, agreed. The original naming was not correct and has been fixed.

> Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.

he library should be able to support this behavior, but it would be important for the caller to know what timezone they should be using: (i) Navajo nation would use a timezone bound to "America/Denver and (ii) everywhere else inside would use "America/Phoenix". [1]

> Among other problems

I appreciate you raising the points above! I hope you can see I am open to feedback and take improving this work seriously. If you are wouldn't mind sharing the rest of what you are seeing, I would be interested in hearing more.

[1] https://en.wikipedia.org/wiki/Time_in_Arizona