Its all in the needs of your application. If your application requires that it uses a different style sheet for the web page based upon it being "day" or "night" in the users timezone, then your concepts of "day" and "night" are pretty clearly delineated. If your application requirements dictate that your user may be crossing time-zones while using it, your defintion of "day" and "night" is then much different, but still very modelable within OO. I find that OO better models "conceptual" objects than it models "real" objects.

To go back to the original example of day/night modeling, it is clear that you are running into the classic OOA/D trap of over-generalization and over-abstraction. Of course you cannot model the entire concept of day and night with OO, but you couldn't describe the concept adequately in natual lanaguage either (at least not on the level of detail needed in a computer system).

In the process of OOA/D you need to know when to stop abstracting things, or you end up with a giant mess of all too specific classes (which will actually make things worse and defeat the whole idea of OO in the first place). You also need to learn when to stop generalizing (which is very much like abstraction, maybe best to say a facet of the act of abstraction). If your classes are too general, you end up with more details/capabilties than you actually need, and again, you've defeated the benefits of OO.

Again, I will say, its just another tool. And like all tools, their usefulness is not so much an intrinsic property of the tool, but instead all in how you utilize the tool.