Gas cost difference between storing/accessing addresses natively compared to converting them to bytes32 or uin256

I've been working on an ERC20 token which requires me to check if a unique hash combination between an address and a timestamp exists, the timestamp is of type uint256. Would it be more efficient to convert the address to uint256 and concat the timestamp using addition then generating the hash using keccak256, or store them in separate arrays? I'm open to any and all suggestions as a novice to smart contract optimizations.

What do you mean using separate arrays?

Using addition to generate your hash preimage does not sound good to me, it's not an injective encoding.

By separate arrays I meant to have to have the addresses stored in an address and the timestamps be stored in a uint256 and generate the hash for the both of them added together and stored in a bytes when the lookup function is called. My original idea was to concat them together to generate a hash that will be stored in a bytes before the look up is called. I'm under the presumption that since the address and timestamp cannot both be identical at the same time, so the resulting hash from adding both will be unique. Is there something I'm not understanding about how this process works? Thank you for any assistance.

Sorry just saw your reply. I really don't understand the situation though!

If this is about gas cost, the answer is always that you should measure both approaches in order to know which one is better.

No worries! I have settled on using a nested mapping instead to map an address to a uint timestamp then mapping the time timestamp to a uint amount. This is a lot more understandable and has a lower gas cost than what I had originally wanted to implement with hashing and arrays.