Thiemos Archiv

Several reasons:

1. The DateTime class does not have properties or methods to access year, month and day individually. You must use the format method to get what you want. It turns out this is not a mistake. Even if a DateTime object knows at some point that parsing a string like "2015-02-29" results in a structure with the month set to 2 and the day set to 29, it always converts this to a Unix timestamp and then back to a structure with year, month and day being individual fields, so the two representations are always guaranteed to be convertible without loosing any information, which is exactly what would happen (and what I want) if you convert "2015-02-29" to an integer and back to a string. Turning this off (which means you must rewrite the whole DateTime architecture) would mean you end with inconsistent DateTime objects that may cause data loss in other parts of your or other peoples systems, that rely on this behavior.
2. It's an intended feature of PHP's date and time parsing that you can ask for stuff like the »last day of the previous month«. You can do this in various ways, including actual add and sub methods as well as strings like "-1 day". Setting a day to zero as in "2015-03-00" is just an other way to trigger this feature. Trying to turn this off would also turn off the intended feature, because it is build in a way that it sets the day to -7 if you ask for stuff like »a week before«.
3. Elements in the intermediate data structure that were not detected during parsing are filled with elements from the current date and time. Again, the whole reason for this is that you can pass strings like "now" or "now -1 day" that are relative to the current day. The parser does not know and does not care if an input string was meant to be relative or not. Again, you can not turn this feature off, because this would screw up almost everything.

Guess I need to get this finished.