I much prefer exposing the DateTimeStrategy rather than adding specialised control flags, this allows the user to implement their own strategy if the built-in options do not suit.
A few questions/suggestions/enhancements:
How about renaming the DefaultDateTime class to LocalDateTime. This would fit better with the name of the UniversalDateTime alternative and is a better description of the behaviour.
Could you add a <value> and <remarks> section to the doc comments for the new DateTimeStrategy property. In the remarks indicate what the default value is; what the expected behaviour of the IDateTime is (to return a timestamp for the event); and list the implementations that are available and how they should be specified in the config file. The nested class syntax is not widely known so it would be good to include a very brief paragraph on that which gives the example: <c>log4net.Appender.RollingFileAppender+UniversalDateTime</c>.
Should it be considered an error to set the strategy to null? Should the DateTimeStrategy setter check for null and throw an exception? The alternative is to leave the m_dateTime null until ActivateOptions. If null then it is set to an instance of DefaultDateTime, then it wouldn't be an error to set DateTimeStrategy to null. I think we need to do one or the other, and probably the second, i.e. the appender tries its best to recover.
Can you commit your patch with the above changes and mark this issue as resolved.