Open LewisDrysdale opened 1 year ago
I think it might be just as well to replace throughout, but it might also be worth tracking down how it happened in the first place since it implies there's somewhere else where a different function was being used (probably; I don't see anything in julian that would cause it to behave differently under certain conditions!). I will look into it a little.
Currently it looks like there are still instances of julian in (JC238-proc-RTmoor) insitu_cal_osnap2.m, is the intention to replace those or is it preferred not to modify old cruises' code (even if in this case it means those segments of code are "wrong" because they're no longer compatible with the way read_rosfile is calculating dates)?
I think it might be just as well to replace throughout, but it might also be worth tracking down how it happened in the first place since it implies there's somewhere else where a different function was being used (probably; I don't see anything in julian that would cause it to behave differently under certain conditions!). I will look into it a little.
Actually, while replacing this, we might as well just use Matlab's datenum. 1) it can handle the decimal hours that rodb format uses; 2) it doesn't require converting to datetime variable type first (both issues I'm running into with trying to use juliandate as it is currently implemented in insitu_cal_osnap2.m in Matlab2021a).
The homemade Julian function is causing strange offsets in the converted time for microCAT and bottle data in caldip processing. This was noticed while processing CTD caldip cast 19. I have replaced Julian with Juliandate (matlab own function), in insitu_cal_osnap2.m and read_rosfile.m . Not sure if we need to replace throughout the toolbox