Barb-B - ok, I think I know what is happening. On my calibre I have read file metadata turned on when adding books, and I am betting you do not. So when I add to calibre, the date field calibre uses to put into the opf file is set, however I am betting you have not updated the metadata for the book, and hence that is why it is storing an invalid date in there.
This is not a bug in Modify ePub, it is really a flaw in calibre in my opinion, though Kovid may not see it that way, either that or Sigil should handle it better. As I predicted above this is the same behaviour you will see if you use the calibre Save to Disk feature to export the book, you get exactly the same "invalid" epub resulting.
So... I suggest you raise a bug request for calibre for Kovid and that way it will be fixed for all scenarios, he just needs to store a better "null date" than his current approach I believe. Of course if he disagrees then you should raise a bug request to Sigil, and ask the devs to handle that date value more effectively. Though the fact that epubcheck shows it as an error would indicate to me at least that really calibre should not be putting such a date value in there.
So for the record, the issue is occurring when the original book has this in the opf:
Code:
<dc:date opf:event="publication">2011-09-27</dc:date>
Which if calibre is not reading metadata from the book when adding, will then on save to disk (or update metadata in Modify ePub) turn it into this:
Code:
<dc:date>0101-01-01T00:00:00+00:00</dc:date>