omega=2.0_r8*pi*time(ng)/Tperiod(itide)
time(ng) is the "ocean_time", that is, non necessarily zero (especially in realistic application) at the zeroeth timestep.
Ephase should be referenced to the value of "ocean_time" = 0.
However, if the actual julian day 0 is far in the past compared to my julian(dstart), irrespective the convention, this would result in an innacurate tidal prediction.
I think it would be more accurate (and intuitive) to set instead:
omega=2.0_r8*pi*(time(ng)-dstart*86400)/Tperiod(itide)
In this case, the time origin of the tidal phase is simply the initialization time, whether it is zero or non zero
Another options may be something like:
omega=2.0_r8*pi*(time(ng)-start_tide*86400)/Tperiod(itide)
where the parameter start_tide is the julian day of the time origin of tidal phases, eventually specified in the file ocean.in so the user can choose whatever he wants
Well, it's just a suggestion
.BTW, tidal currents are rotated (if needed) in clm_tides.F when CURVGRID is defined. It would be more coherent to rotate tidal currents outside the code just as we usually do with all the other non-scalar forcing, instead of rotating something outside the code and something else inside.
Best
Jacopo