Emphazise reasoning against generic UTC

Author: heiglandreas

proposed/clock-meta.md

@@ -142,6 +142,31 @@ _**Note:** Order descending chronologically._
 
 ### Why not simply convert all times to UTC?
 
-Timezones change! Regularily! And unforseeably! So when you are converting a DateTime in the future to UTC you are using the offset that is known today to convert from the local time to UTC. When that offset changes between now and the datetime then you have no chance to adapt to that. 
-An Example: in  summer 2016 you scheduled an event in turkey for 14:00 on the 25th of December 2016. With the information known in summer 2016 you would calculate that that is 12:00 UTC. What you couldn't imagine is, that the Government decided later that year to stay on daylight saving time and not go back to standard time for the winter. So when the time comes you would show up at 12:00 UTC. With the then relevant timezone information that would be 15:00 local time. But your appointment was at 14:00 local time. Would you have *not* converted to UTC you would have stored `14:00 Asia/Istanbul` and you would have been on time.
-**Note:** While this might only seem relevant for future datetimes it illustrates that transposiing between timezones can cause much more confusion than just keeping and using the existing timezone information. 
+As timezones are based on political definitions. Therefore they change: regularily and unforseeably. And sometimes even
+for past times. So when you are converting a DateTime to UTC you are using the offset that is known today 
+to convert from the local time to UTC. When that offset changes due to political decisions then you have no chance to 
+adapt to that. 
+
+An Example: In  summer 2016 you scheduled an event in turkey for 14:00 on the 25th of December 2016. 
+With the information known in summer 2016 you would calculate that that is 12:00 UTC. What you couldn't imagine is, 
+that the Government decided later that year to stay on daylight saving time and not go back to standard time for the 
+winter. So when the time comes you would show up at 12:00 UTC. With the then relevant timezone information that would 
+be 15:00 local time. But your appointment was at 14:00 local time. Would you have *not* converted to UTC you would 
+have stored `14:00 Asia/Istanbul` and you would have been on time. 
+
+**Note:** While this might only seem relevant for
+future datetimes it illustrates that transposing between timezones can cause much more confusion than just keeping 
+and using the existing timezone information. And as there have been requests to the timezone database maintainers like
+"We changed from offset x to offset y 2 weeks ago" or "we will change from offset x to offset y tomorrow" that can also
+concern your current conversion from local time to UTC. So to avoid confusion is to avoid transposing between timezones
+as much as possible and save it to the last possible moment.
+
+`now()` should be considered to be the equivalent of checking your wallclock at home or your wristwatch. It usually 
+gives you the current point in time at your current location. And from that point you can then – if you 
+need to – transpose to other timezones. That makes life much easier than setting your wallclock to UTC and 
+having to transpose every time you want to communicate with someone. 
+
+As this interface is a generic interface it can not impose a certain usecase and therefore needs to be as open
+as possible. That means to allow people to use any DateTimeImmutable object possible. And that also means to 
+make sure users understand the consequence of that. Which is that it is the users requirement to make sure the 
+returned DateTimeImmutable object conforms to their requirements.