So maybe you could make every date an Unix timestamp, which is an integer, then you get the difference between those integers, then you can use an standard or min max scaler to put it under a certain interval.

I do not think anyone ever encoded dates as embeddings the way you're proposing, just because you can already get these kind of representations by using Unix timestamp.

If I understood you correctly, you can handle dates and diffs of dates as a diff of Unix timestamp representations of these dates. Any programming language should have a time data manipulation lib and should offer APIs for converting dates to they Unix timestamp values. It is an approach, but has its limitations. Using months, days and years as different features is also possible. Using cyclical encoding of dates is also possible, buy I use to see this kind of thing only when dealing with the hours, minutes and seconds of a date. Embedding these dates, if we're talking about embedding dates by using an ML algorithm to generate these representations, seems a really, really bad idea, as, in my point of view, it adds work without adding any benefits to your solution. If you're not talking about that, then sorry, but I couldn't understand what you meant by taking about these "embeddings of dates" :)

take a look at auto-encoders for data compression ;)