is a creation date included anywhere in the PKCS12 structure which would account for the checksums of two PKCS12 files matching if they are created on the same day, but otherwise not?
No, not by default and not by OpenSSL.
is there any way to define this creation date when PKCS12 files are created?
Not applicable.
are there any other factors which could account for this behaviour?
Yes, the salt used during password based key derivation. This would be included with the store. It would also change MAC creation which is usually included for integrity / authenticity.
Moreover, if anything is encrypted then the derived keys would also differ due to the salts used. This is commonly the case if you also import a private key. The IV is however derived from the password and keys.
So in your case I would not rely on a binary comparison. Instead, extract the certificates, retrieve the SHA-256 fingerprints of the certificates, sort and compare them.
This implies that you are probably only generating the PKCS#12 store daily, as any newly created store should have a lot of changes. I've established this on my system using the command you've listed.
In general you should not rely on binary comparison or cryptographic hashes unless you can be sure that the data is already present in a canonical form. This for instance would be the case for DER-encoded certificates - which is why certificate fingerprints can be used to compare certificates.
It won't necessarily work for any other files, for instance for encoded binary files where the format leaves room for non-semantic changes. This is for instance the case for PEM encoded certificates where the character encoding, the amount of base 64 characters per line, differing additional lines, whitespace all can change without altering the binary content of the DER encoded certificate within.
Of course, if you are using a specific version of OpenSSL the PEM encoding of identical certificates is unlikely to change. Still, I would warn against assuming that this will hold in time. Use the x509 fingerprint option instead, e.g. openssl x509 -in crt.pem -noout -fingerprint -sha256. A future developer will otherwise be baffled looking at the screen, after a slight version bump or change of the tooling used.
This also goes for the key store. If a future version would include a date (in a bag) or different ordering, encryption, key derivation or MAC scheme then you'd be in trouble even if you'd manage to always use the same salt. Too many developers, especially of scripts rely on assumptions on what data is present and how data is represented.
