Now I understand better what do you want to do. Ok. you need the timestamp - probably the date from them will be enough as key and the time-part could be removed or separated as additionally information or maybe linked per separated master timetable - but I think you don't need to link the different timestamp-fields together else keep them dimension-table and the related master-calendar as separated datamodels. A link-table approach with a canonical calendar might be possible but I don't see the added value for them. Take a look here:
I think I'd add a timestamp to each dimension table and qualify it so the fields don't result in a synthetic key. You can use those fields to show timelines for each dimension. You can create a data island calendar table or just use variables to select a period. You can use set analysis expressions to filter the values of the timestamp values in chart expressions using those variables to make each chart show the same period.
You just won't be able to show multiple dimensions in the same chart/table object. If you need that then you need to create additional tables that are not associated (linked) to your fact table. Perhaps that's an easier option. Your fact table doesn't have a timestamp field anyway. You can then simply concatenate all your dimension tables into a new table and add a timestamp field in that new table at the same time. Qualify the fields in that table to prevent synthetic keys.
I agreed with Gysbert suggestion regarding qualifying your time-stamp columns (first paragraph), I suggested that approach in your other thread.
I do not extend my reply on how to consume these timestamps because there is not a clear definition on how you want to implement this logic, e.g. a part of your current application or in a different application.