On your titular question: Should I override controls so that it handle different locale's or let the browser handle it?, my "go to reason" for not relying on a browser's locale is the situation where someone from the UK arm of a multinational company is visiting the company's offices in France and using a PC there.
If the web application is relying on the browser's settings (which more than likely will be set to "French") then the person from the UK has to change those settings, and – if they are being considerate to their hosts – may need to change them back.
On the other hand, if the web application has its own way of changing language/locale, then not only will the UK user probably not have to worry about resetting things, they may also never need to change the setting in the first place:
- If the app never saves the choice (beyond the current session), there's nothing to reset (but anyone wanting to change the locale will have to do so every time).
(Assuming users log into the PC with their own username: very likely in a corporate environment):
If the app saves the choice in a cookie, then the first time someone new uses a given PC, they won't have a cookie and will need to select the locale. Thereafter, when using the same PC they will see their preferred language. Other users (with their own cookies) will not be affected.
If the app remembers the user's choice within the app itself, then when "TripeHound" logs in, not only will my choices not affect anyone else, the chances are the app will already know I prefer English and I won't need to change anything.
(Only if the app stores the choice in a cookie, and everyone logs into PCs with a generic account would the setting need to be reset. This is an unlikely scenario in a modern business setting. I hope! Nowadays, even in a non-business setting it is common for different people sharing a PC to have their own accounts.)
As to the question at the bottom of the question body: should you (continue to?) use custom components to support browsers that don't fully respect the
lang= attribute? First I'd note that that seems to be more of a "How do I implement..." question (compared with a "How should I design..." question that SE:UX prefers), nevertheless...
Any answer would depend on how important you feel it is for dates/
required elements to be fully localized, and how far off you "guestimate" full compliance by popular browsers might be:
If it's very important to fully localize, and some mainstream browsers currently don't comply, customized controls is probably the answer. (They won't stop working even if browsers catch up).
If full localization is not vital, but more desirable than nice to have, and you've already got customized components (or can lay your hands on suitable implementations of them), then you may as well use them now, at least until browsers catch-up.
If full localization is only nice to have, but browsers seem to be moving in the right direction, you might decide that standard controls are "good enough" for the time being, and will be "perfect" when browsers do catch-up.