Ah right. I didn't think of this problem.
Invalid date/times may give unpredictable results. If they are inside the
range for strftime, they are usually handled reasonably (ie. a day of "0"
is actually the last day of the month before, and a month of "0" is December
of the year before). So if you set
-DateTimeOriginal="2007:00:00 00:00:00", and then read
it back again with -d %Y%m%d -datetimeoriginal, you will get
"2006:11:30". Which may not be what you expected, but makes more
sense date-wise.
But the year "0000" is obviously not being handled properly, since it
is well out of range for strftime.
So this becomes a slightly trickier problem than I initially thought,
particularly since the conversion of 0000:00:00 is likely to be system
dependent (although on my Mac here it also gives 0000:00:02).
But at least on your system you can check for /00000002_000000/.
It isn't pretty, but at least it gets you going.
(5)
]
