Datenum: how many seconds in a day?

Datenum converts a date to a number representing the number of days past since a certain initial date. The documentation of datenum doesn't seem to say anything about this, but what is meant exactly by a day?

Is the day exactly 24h, i.e. 86400 (SI) seconds? Or is it a solar day?

If it is the former, how does it match with real life dates? By adding leap seconds? If so, a day is not (necessarily) exactly 86400 seconds; and how do I know when there are leap seconds and how many?

If it is the latter, how do I know how many (SI) seconds there were/are/will be in that day?

Thanks in advance

Answer 1

[James Tursa]

With regards to the datenum and related functions, MATLAB days are exactly 24h (86400s) always. There is accounting for leap days in calendar date conversions, but NO accounting for leap seconds. There is also no accounting for time zones. So it is up to the user to use the functions properly as MATLAB gives you no help here. That is, you can use the datenum family of functions to work with local times or UTC based times or TT based times, but you need to know what you are doing and make any adjustments (time zone, leap seconds, etc) yourself to get the correct result.

To quote the doc, the "now" function "... returns the current date and time as a serial date number." Since this is obtained from your computer's clock, and since your computer likely updates its clock from a UTC based server with time zone correction, what you get with the "now" function is a local time zone corrected UTC based time. UTC based times have leap seconds applied to them, so it is not a continuous time scale.

If you need to convert to a continuous time scale like TT or GPS, you will need to get a 3rd party conversion function. Basically, a table look up to account for leap seconds and then a constant offset will do the job. For example, astronomical algorithms typically take a TT based time as an input (to get planet positions, etc), so if you are trying to see where a planet is at 10pm tonight you would need to convert that local UTC based time to a TT time before feeding it to the astronomical algorithm. Online programs typically do this conversion for you in the background, but if you are writing a program yourself you would need to include that conversion in your program.

I think I have a MATLAB based UTC -- TT conversion program if you need it, or you might be able to find one in the FEX (I haven't looked).

[Lukas]

Ok, so say I wanted to calculate the number of seconds between 2014-03-10 00:00:00 UTC and 1972-01-01 00:00:00 UTC (when UTC and leap seconds were implemented) and I would use

(datenum(2014,03,10,00,00,00)-datenum(1972,01,01,00,00,00))*86400

my answer would be 25 seconds off (the amount of leap seconds added since 1972)?

Is this correct? (I didn't realize there were this few leap seconds and I actually don't really need this kind of precision, so don't want to waste anyone's time, but it is interesting nonetheless)

[James Tursa]

If "number of seconds" means "what I would have recorded with a continuous stopwatch", then yes, your answer would be 25 seconds off.

[Lukas]

ok, thanks

[Phillippe]

If Matlab treats a day as 86400 s, why does

( datenum('3 Sep 2014 17:00:00') - datenum('3 Sep 2014 16:00:00') )*24*60

not return exactly 60? Instead I get 60.000000111758709, which is more significant digits than I would expect from simple round-off error. Am I missing something?

I found that

datevec(datenum('3 Sep 2014 17:00:00'))-datevec(datenum('3 Sep 2014 16:00:00'))

returns exactly 1 hour, but I'm not sure why this would work when datenum by itself does not.

[James Tursa]

Because datenum stores the entire date information (day,hour,minute,second) as a single double precision number, so the seconds part of it is not accurate down to the precision you are showing. datevec apparently has smarts in it for conversions to recognize that those trailing digits are garbage and 0's them out for you.

Answer 2

[Thomas]

IF my guess is right matlab considers every day as 86400 seconds.. only in leap years does datenum make sure an extra day is added to the calendar in february..

a=datenum([2012,2,1,12,00,00]);  % leap year feb 
b=datenum([2012,3,1,12,00,00]);
b-a   % leap year feb 29 days 

c=datenum([2013,2,1,12,00,00]);
d=datenum([2013,3,1,12,00,00]);
d-c    % no leap year feb 28 days

So the extra seconds are added on that day..

Answer 3

[Star Strider]

That question interested me enough to do a search. I can’t determine if MATLAB corrects for leap seconds and such (my guess is that MATLAB uses the SI day). The Astronomy & Astrophysics package for Matlab is the only site I found that might have what you want. It’s encyclopedic, so I just scanned it.

MATLAB tracks time only to the millisecond in its date and time functions, and day length variations seem to be significantly less than that. You probably have to do your own corrections to get variations in and different definitions of day length.

[Lukas]

thanks

Answer 4

[Sean de Wolski]

It might be worth looking into the datetime class in R2014b. This allows you to account for leap seconds:

http://www.mathworks.com/help/releases/R2015a/matlab/ref/datetime-properties.html

[James Tursa]

I looked into this. See this link:

http://www.mathworks.com/matlabcentral/answers/184267-datetime-utcleapseconds-2-second-difference-across-leap-sec-boundary

Answer 5

[Peter Perkins]

Just to summarize and expand on what several people have said:

1) The datenum, datevec, and datestr functions work strictly in terms of 86400s days. Beyond what your system may or may not return when you use the now function, there is no accounting for leap seconds (they are treated as if they did not occur), and no time zone or daylight saving time support, although they do account for leap days. What those "seconds" mean is entirely up to your interpretation, those functions make no assumptions about solar days vs. SI days, or even about things like TT vs. TAI vs. GPS time. The interpretation becomes important when you want to convert between systems. And of course UTC does include leap seconds, so it's not continuous, although I suspect that most people wish that wasn't the case. At any rate, datenum, datevec, and datestr treat every day as 86400s long.

2) Since R2014b, MATLAB includes three new data types: datetime, duration, and calendarDuration. These allow you to opt in on support for time zones and daylight saving, and even for leap seconds. They also provide much higher precision, so Phillippe's example becomes

>> d = datetime('3-Sep-2014 17:00:00') - datetime('3-Sep-2014 16:00:00')
d = 
   01:00:00
>> minutes(d)
ans =
    60

There is not yet support for GPS time or TAI in datetime. But again, in a continuous time system that ignores leap seconds (which is what you get by default with datetime), you can interpret the times however you want. It's only when converting to other systems that you have to be careful.