Need MWE (minimum working example) to illustrate the problem -- you didn't provide the needed data to run the above -- time and YearDay.
But, there's a least one logic or typo in the above, the code snippet
...+doy2date(YearDay,2022*ones(length(time))
looks to be missing the traling ",1); to create a column vector; as is it would be an array of NxN
Time=datenum(time,'HH:MM:SS')-fix(datenum(time,'HH:MM:SS'))+datenum(2022,0,YearDay);
should do the trick; datenum will expand single value arguments automagically, so should the FEX submission if you're bound and determined to not chuck it over...
One could write the above as simply
startTime=datenum('23:00:00','HH:MM:SS')-datenum('2022','yyyy')+datenum(2022,0,260);
endTime=datenum('0:10:00','HH:MM:SS')-datenum('2022','yyyy')+datenum(2022,0,261);
and remove the dependency upon the external FEX function; that's all it's doing under the hood.
Also, in
...datenum('23:00:00','HH:MM:SS')-datenum('2022','yyyy')...
the use of "2022" in the correction is not robust; the default y,md for datenum when text strings contain only time information is Jan, 1, CURRENTYEAR. The above will work until next year at which time it will be a year off. It would be better to encode a fixed reference year into the first argument or eliminate the need for the fixup in the above manner by saving only the fractional part as
datenum('23:00:00','HH:MM:SS')-fix(datenum('23:00:00','HH:MM:SS'))
which has the performance disadvantage of computing the same datenum value twice; of course, you're calling datenum twice't anyway, both with missing portions of the date/time string which undoubtedly causes at least some extra work internally.
As far as the actual Q?, you're probably seeing the effects of floating point rounding, but without the actual numbers, can't tell that for certain. The new datetime class would undoubtedly make the above go away; unless you're really restricted for other reasons, upgrading would be beneficial.
