Hacker News new | past | comments | ask | show | jobs | submit login

I've always felt that if you can't handle changing a clock twice a year, then there's probably something fundamentally wrong with your ability to handle much more complex problems. Like deciding what's for lunch.



Well, turning a dial on your wrist or pressing a few buttons is one thing, but when it comes down to code you're looking at a lot more complication than that.

Knowing how to correctly handle time as a programmer is anything but trivial. It's so not-trivial we even have a database of historical changes in timezones and DSTs in order to maintain backwards compatibility for it.


Is that your argument against simplifying things? That people should be able to handle unnecessary complexity?


After years of trial and error, we've determined that the simplest way to change the clock in one of the in-built appliances in our kitchen is to kill its electrical power completely for a few minutes (by tripping the appropriate MCB in the consumer unit), then powering it back up.

When the power is restored, the appliance knows it's experienced a power cut, and asks for the current time.

Yes, this is completely ridiculous. No, I don't know why they designed the UI this way.


You could say the same exact thing with regards to the time on the clock, though. Like, there's no reason that sunrise couldn't be at <arbitrary time>. If we used one worldwide timezone you'd just...wake up at different times depending on where you are instead of it BEING a different time depending on where you are.


I rarely have to deal with changing a clock. The real pain is having to deal with DST and strange timezones while programming.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: