Hacker News Reader

> Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month.

You think there's much of an overlap between systems that do time zone arithmetic with naive timestamps and ones that bill in the customer's time zone?

> Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month.

Yeah, so the compiler should issue a warning and the user can decide how to proceed. If the user ignores the warning for code that is part of their company's billing system, that's on them. Computers should provide information, but ultimately leave the humans in charge.

> The problem, of course, is that most programming languages don't have a concept of "pinning the allowed runtime version like any other dependency"; or of the runtime exposing an ABI version that increases for every breaking change.

That's an equally fine way to handle things IMO, but the language would need to support each runtime version more-or-less indefinitely. It also still doesn't solve your problem with the customer in Tuvalu (which I think is fine, just pointing it out).

Fwiw, that's what's currently happening with this function, it is deprecated only, and I don't think there's a clear deadline yet on at what point it will officially get removed. So no code will stop working in the near future, and any code that does use this function will simply get a very clear warning pointing them in the correct direction.

Yes, but the message clearly states it will be removed in the future. IMO they shouldn't do that. Deprecate indefinitely.

> Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month.

A one-off is not "whole billing system falls over". These things are inevitable because bug free software never happens, and so humans exist to deal with these situations. Unlike what an update that changes API would do. Now you can't update unless you rewrite everything, and you certainly will have regressions just because of this rewrite

> Sure, it all seems to work for now... and then a customer signs up from Tuvalu, and performs a billable action at 11:59PM on the last day of the month, and your whole billing system falls over because they now have a split invoice generated for next month while it's still this month.

Then you issue a refund and fix the problem, not lock everyone out of the system.