No question that a long is "overkill" for representing the number of .dat files we'll have. However, we selected System.currentTimeMillis() because it would give us a unique, increasing number every time. Storing an additional 7-10 bytes per filename seems like a reasonable tradeoff.
As far as the question of zero-fill, it's actually pretty moot, because it will only matter when the length of the timestamps increases by a full order of magnitude. For today, that means going from around 1.2 billion seconds since epoch to 10 billion seconds since epoch, which is about 300 years from now. Even then, the problem would only manifest if two log files were created across the 10 billion rollover. Do you think that we can be ok with a 1-second danger zone 300 years from now?