milliseconds time conversion problem

I'm trying to print the milliseconds field with the following

DS = datestr(MM,'HH:MM:SS.FFF')

the SS.FFF field is rounded up to the nearest second

ie. 59.000

So on the command line I input

K>>MM = .9833

then K>> ZZ = MM * 60.00

the returned value for ZZ on the command line is

59.00

The interpreter shouldn't know if this is anything other than a double multiplied by a double returning a double not a time value.

How do I get around this and how can I print HH:MM:SS.FFF in my code?

[Oleg Komarov]

I don't have any problem with

MM = .9833

DS = datestr(MM,'HH:MM:SS.FFF')

[Michael]

Hi Oleg,

I restarted Matlab and set the value of MM and performed the commandline calculation

ZZ= MM * 60. With a fresh restart I got the milliseconds. I then did the following.

JD = 97.9833

sprintf('%3d %s', fix(JD-rem(JD,1)), datestr(JD,'HH:MM:SS.FFF'))

This is what was returned....

ANS =

97 17:36:59.000

wher 97 is the julian date but the SS.FFF filed was rounded up to the nearest second.

[Walter Roberson]

JD = 97.9833

>> datestr(JD,'HH:MM:SS.FFF')

ans =

23:35:57.120

Notice this is different than the times you get. I am using 2008b.

It does not appear to be single() vs double() as in my release datestr() will not accept single()

Arithmetically, consider

>> .9833 * 24*60

ans =

1415.952

That is, 0.9833 of a day is 1415 full minutes and 0.952 partial minutes. Multiply that by 60 and you get 57.12 -- 57 seconds and 120 milliseconds, just as is calculated on my system.

Please repeat those calculations on your system and see what gets returned.

[Walter Roberson]

Note that if JD is a Julian Day then there needs to be a 1/2 day conversion and possibly a timezone conversion in order to get the local time. There are different Julian Day standards with different corrections; see http://en.wikipedia.org/wiki/Julian_day

These corrections could account for the hour discrepency (23 vs 17), but I do not see how they could account for the difference in minutes and seconds.

Answer 1

[Walter Roberson]

Michael, which MATLAB version are you using?

Also please check that none of your values are single precision numbers. In the time range of today, eps(datenum(now)) is about 11/10 of a millisecond so if you were using single precision or a far future date, you could run out of precision.

[Michael]

Thanks I will revisit the precision of the datenum result.

The actual value is 7.346007283912037e+05

[Michael]

Hi Walter,

I found this under Serial Number Dates;

Working with Serial Date Numbers

A serial date number represents a calendar date as the number of days that has passed since a fixed base date.

In MATLAB, serial date number 1 is January 1, 0000. MATLAB also uses serial time to represent fractions of days beginning at midnight; for example, 6 p.m. equals 0.75 serial days. So the string '31-Oct-2003, 6:00 PM' in MATLAB is date number 731885.75.

The fractional part is the only part of interest in the time calculation. Could it be a problem with verion 2010b?

Different input value this time.....

K>> Billy= datestr(.7283912037,'HH:MM:SS.FFF')

Billy =

17:28:53.000

[Walter Roberson]

That one is 52.9999996799961 seconds. Is it important that those 3/10-millionth of a second cause the result to be output as 52.999 ?

Answer 2

[Michael]

Hi Walter, I'm using 2010b. I was wondering about a type mismatch issue but here's another pass at the command line.

K>> datestr(.734016203670760,'ss.FFF')

ans =

59.000

   Looks like something internal to the datestr f(x).

[Walter Roberson]

The source to datestr.m is provided. You should be able to step through and see what is happening.

[Walter Roberson]

I am a bit confused by the similarity between the .734016203670760 and the 7.346007283912037e+05 of before -- both start with the digits 7340, but they are e+04 in magnitude apart.

[Michael]

I've tried multiple work arounds including writing my own time conversions.

K>> HH

HH =

17.481388888321817

K>> MM

MM =

28.883333299309015

K>> sprintf('%2d:%2d:%2.3d',uint8(HH),uint8(MM),uint16(Secs))

ans =

17:29:053 Notice what happened to the minutes!

I found this commentary in the Matlab help regarding truncation...

Integer Data Type Functions Now Round Instead of Truncate

The following integer data functions now round noninteger inputs instead of truncating:

int8, uint8, int16, uint16, int32, uint32, int64, uint64

For example, in MATLAB 7.0,

int8(3.7)

returns

ans =

4

Compatibility Considerations

In previous releases, the same command returned 3. If you have code that contains these functions, it might return different results in Version 7.0 than in previous releases, in particular, results that differ by 1 after converting floating-point inputs to an integer data type.

You can turn the following warning on to help diagnose these differences:

warning on MATLAB:intCovertNonIntVal

See New Warnings for Integer Arithmetic for more information about this and other new warning messages.

Now I'm looking for a truncate function to call and I can't find one. My data acquisition system is accurate to microsecs and I have to be able to print that. I'm getting concerned. BTW, Thanks for your efforts Walter (and everyone).

[Walter Roberson]

fix() and floor() truncate.

What you are looking at came in in R14, long before the R2008b that I am using, so it would not be responsible for any differences.

[Walter Roberson]

sprintf('%02d:%02d:%02d', floor(HH), floor(MM), floor(Secs))