Apparently the entity today known as Sharp sells “AccuSet(tm)” branded clocks that “automatically set time”… but they’re just factory pre-set with a button cell and they include a slider on the bottom to set a timezone offset (only for US timezones). If you’re lucky, the clock’s battery is still good and the clock “set itself” out of the box several minutes late.
If you’re unlucky - surprise, you get to manually set the time anyways.
https://www.amazon.com/Sharp-Digital-Alarm-AccuSet-Automatic...
I know this because when my mother was visiting the US over a decade ago, she found a clock she felt was aesthetically perfect for her psychology practice room at her house.
Twice a year the clock changes its time to be 10 hours (or thereabouts) behind, no doubt due to daylight savings change over.
So she has to readjust the time whenever this happens which she says she doesn’t really mind.
We tried “typed” strings like this on a project once for business identifiers.
Overall it worked in making sure that the wrong type of ID couldn’t accidentally be used in the wrong place, but the general consensus after moving on from the project was that the “juice was not worth the squeeze”.
I don’t know if other languages make it easier, but in c# it felt like the language was mostly working against you. For example data needs to come in and out over an API and is in string form when it does, meaning you have to do manual conversions all the time.
In c# I use named arguments most of the time, making it much harder to accidentally pass the wrong string into a method or constructor’s parameter.