The approach will differ depending on your precise use-case.
If you are going for securities regulation compliance then that topic is too complex for a quick answer, so let's just set that aside. There are two other cases.
If the nature of the tokens is actually different then you need non-fungible tokens. Here's a quick way to consider if this is the case. After all the lock-in periods have expired, would it ever be feasible and valid to add two sums together and track it as a single balance? That is, if Alice has 100 unrestricted tokens and receives 50 more unrestricted tokens, is it enough to know that Alice has 150 unrestricted tokens? Yes, if they are all entirely the same. No, if they have other unique properties such as serial numbers.
If "No", they are not the same and cannot be pooled like that, then look into ERC721 and variants.
If "Yes", they are "fungible" and you have conflated the sale process with the nature of the tokens. That will lead to confusion.
You can have fungible tokens with lock-in periods. In this case, you would use ERC20 which does not (nor should it) cover the lock-in concern. Instead, you would create a sale contract and a lock-in contract. The lock-in contract would function similarly to a term deposit, holding funds (tokens) on behalf of a depositor and stubbornly refusing to release them to anyone else, or to the depositor prematurely. Integration of the sales process and deposit contract would ensure that tokens sold are automatically sent to the deposit contract per the terms of the sale.
Hope it helps.
Can we bind "token purchase timestamp" with each token which never changes irrespective of transfers?- of course, but ERC20 does not support this (all tokens are minted "equally"), so you'll have to implement it yourself.