Is it actually possible to use datetick?

I have a cell array of timestamps with the format:

'2014-10-06 09:27:34'

I converted this to a datetime type using:

t = datetime(Date, 'InputFormat', 'yyyy-MM-dd HH:mm:ss');

Then, I made this into a DateNumber, so I could use it as the x-axis for a plot:

DateNumber = datenum(t);
plot(DateNumber, myData)

I tried to convert the x-asix to something readable using datetick. I only care about the hours, minutes and seconds , so I entered:

datetick('x', 'HH:mm:ss')

However, all my ticks say 00:10:00 no matter how I zoom in on the axis. Also, if I change the axis limits using the plot tool before I run datetick from the command line, it reverts to the old axis limits.

I tried plotting a small subset of my data (80 points) that was taken between 4:52:56 and 6:25:46. My plot only gets five ticks, 04:10:00, 05:10:00, 05:10:00, 06:10:00 and 06:10:00. How are these 'repeat' ticks possible?

If I look at the contents of DateNumber using datestr:

datestr(DateNumber(2550))

ans =

08-Oct-2014 04:52:56

I get back the values I expect, so it looks like the DateNumber variable is filled properly. The problems seem to be with datetick.

[dpb]

Attach the data file and edit the code snippets to produce the axis and time ticks that are the problem there so others here can try to reproduce/solve the exact problem.

In general, yes datetick works (albeit it is some what clumsy rather than there being a builtin time-scale axis setting a la 'linear','log' that would be the rational thing to have done). One problem one tends to have is that there simply isn't enough room on the axis for the text when get more than just a few ticks but that's really not datetick's fault.

Answer 1

[Sean de Wolski]

With datetimes, if you plot them it takes care of datetick for you:

plot(t)

It's a new feature in 14b and it will update when you zoom.

[Victoria]

I'm using 14b. If this is true, you need to update your documentation. It is terribly out of date and therefore not useful. Example 1 'Label x-Axis Ticks with 2-digit Years' on the datetick page in the 2014b documentation says you need to convert an array to a datenum before you can plot. And the datetime page says nothing about plotting or working natively with plot to do datetick. http://www.mathworks.com/help/matlab/ref/datetick.html http://www.mathworks.com/help/matlab/ref/datetime.html

[Victoria]

The page you recommended below http://www.mathworks.com/help/releases/R2014b/matlab/matlab_prog/plot-dates-and-durations.html is useful, but it's ridiculously hard to find if you're searching through the datetime doc for the first time. Please link to it from the pages for datetime.

[Campion Loong]

Victoria, this is a good suggestion. I will follow up with our documentation team to include more references to the new datetime plotting feature at relevant places.

In case you'll find it useful in your workflow, this plotting feature also works on duration arrays. It is another new datatype in 14b that often comes up as a result of datetime arithmetic calculations.

[dpb]

Even better would be to get the development team to fix the incompatible date formatting strings between this new class and the long-existing date number routines. I can see no justification for such and if hadn't done that, Victoria wouldn't have had the problem. Of course, if she hadn't uncovered it, it was only a matter of time until somebody else is tripped up by it.

[Iain]

In older versions, you can achieve the same effect by attaching a callback to the zoom event on the chart, which issues the datetick command, with the option to not revert the chart back to the initial state, like datetick normally does.

Answer 2

[dpb]

Overlooked the likely culprit earlier...

t = datetime(Date, 'InputFormat', 'yyyy-MM-dd HH:mm:ss');

Then, I made this into a DateNumber, so I could use it as the x-axis for a plot:

DateNumber = datenum(t);
plot(DateNumber, myData)
datetick('x', 'HH:mm:ss')

Bum format strings...use lowercase for yr,mon,day, UPPERCASE or HH,MM,SS

I'll bet

datetick('x', 'HH:MM:SS')

will work as advertised; post back if not with earlier requested additional data.

BTW, similar with the date format in the datetime argument; you've intermixed date and time format strings for some reason. My version predates the introduction the this class so don't know how it handles it.

You can eliminate at least one step as

t = datetime(Date, 'InputFormat', 'yyyy-MM-dd HH:mm:ss');

Then, I made this into a DateNumber, so I could use it as the x-axis for a plot:

DateNumber=datenum(Date,'yyyy-mm-dd HH:MM:SS');

If you're only plotting and not doing other lookup or searching for dates, then you can fold the datenum call into the plot call as well and eliminate the extra variable(s) entirely.

[Victoria]

I don't think this is right. I looked up the string formatting and as far as I can tell HH:mm:ss is the correct notation for hours minutes and seconds in MATLAB. MM is definitely for months, NOT minutes. It will even give you a nice error message if you try with a datetime.

Warning: The format 'HH:MM:SS' contains a field for month (M) in what appears
to be a time portion. You might have intended to use the symbol for minute (m)
rather than for month (M). See the datetime.Format property for a complete
description of the identifiers used in format strings.

[dpb]

That truly sucks(+)...TMW has two inconsistent formatting schemes then...

http://www.mathworks.com/help/matlab/ref/datenum.html?searchHighlight=datenum#inputarg_formatIn

for datenum shows that time hr,min,sec are all uppercase while the date fields are lower.

To demonstrate the likely problem you saw in datetick...

>> ts='2014-10-06 09:27:34';
>> datenum(ts, 'yyyy-MM-dd HH:mm:ss')
ans =
 7.3640e+05
>> datestr(ans)
ans =
06-Mar-2016 09:10:34
>> datenum(ts, 'yyyy-mm-dd HH:MM:SS')
ans =
 7.3588e+05
>> datestr(ans)
ans =
06-Oct-2014 09:27:34
>>

Note while datenum isn't smart enough to flag this particular problem in the format string (but it could be, just isn't implemented currently) it doesn't return the answer you would hope for. Note that the correction for datenum/datetick combination I suggested does get the input value back.

Now, since you used the datenum class formatting with datetick, I'm still betting that's an issue.

(+) How in the world does TMW expect users to be able to keep this straight and why in the world would anybody mix case in the format strings for a given set of values (days vis a vis time)??? Makes absolutely no sense whatsoever.

PS. My frustration for such incompetence shows, obviously, but it's not you; it's TMW that's the target here...

[Peter Perkins]

dpb, I hear what you're saying, but let me try to explain the reasons behind this change.

First, some background. The new datetime data type is intended (ultimately) as a replacement for the trio of datenum/datestr/datevec. It provides a dedicated data type to do the things those three functions do, and much more, and much simpler. With plotting, for example, you just say plot(t,x). No need to call datetick. The plotting functionality isn't all in place yet, and so in the short term, you sometimes need to use datenums to achieve fine-grained control over choice of date/time tick locations in a plot (this is explained in the doc). But ultimately, datetime and its siblings duration and calendarDuration should replace datenum/datestr/datevec for almost everyone. (I can't imagine that the latter would just go away, there's too much MATLAB code that depends on them. But the intention is that there'd be no good reason to use them in new code.)

So, the "old" datestr way of specifying date/time fields in a format string was case-insensitive except for m vs. M. It also treated any character not specifically defined to be a format specifier as a literal. These two behaviors boxed us in and prevented us from adding support for new fields that customers had asked for. For example, there was no good way to add "day of the year", because d and D meant the same thing. There was no good way to add "time zone offset", because every unused alphabetic character was already treated as a literal.

So a redesign for format specifiers was a necessity going forward. The old syntax was specific to MATLAB, and we could have defined another new MATLAB-specific syntax.

Instead, we decided to use the CLDR standard. In doing so, we recognize that there will be some pain and an adjustment needed. M(month) vs. m(minute) and s(second) vs. S(fractional second) are the main examples. But we felt that sticking to an independently-defined standard was more important than short-term muscle memory. datetime is a replacement for datestr, not intended to be something you'd use at the same time, so there's not really a need to "mix" the two format syntaxes, and speak both of them at the same time.

With the new syntax, datetime supports both "day of the month" (d) and "day of the year" (D), and adds "time zone offset" (X, among others). The existing design of format specifiers used with datestr could not support those in any reasonable way.

The confusion for Virginia (I think) was in converting to datenums and using the datetick function when needing to plot datetimes. In most cases (at least for line or scatter plots), that isn't necessary. This includes zooming and panning. In the longer term, it won't be necessary at all.

[dpb]

So probably the biggest problem is introduction of a new class before it's "fully ripe" and the class methods/properties are fully developed.

Seen other instances similarly with the plotting methods for the specialty plots not yet implemented when the initial class is let into the wild -- the one I recall specifically was no .semilogy[x|y], all the user got was an error on "not supported for class double" or the like which is less than informative.

It seems to me there's as a general tendency too much of a rush to release new features in Matlab. I've compared before the difference between it as a proprietary language vis a vis a Standard-ized one such as Fortran where owing to the Standards process time between changes is quite a long cycle and changes are constricted far more closely because of needing agreement amongst the disparity in interests reflected by the members of the committee and the extremely high priority placed on backwards compatibility. While introducing new features much more rapidly has some benefits (even I have appreciated some of the features in R2012b vis a vis my previous R12 release :) ), some of these issues could be alleviated if not avoided altogether by waiting for release until the gestation period had been allowed to run to its full cycle.

I also am concerned about the increasing footprint the present tack has on the product. By introducing all these new classes as replacements for existing functionality as well as the new higher-level data abstractions, the system requirements have risen dramatically. R12 on the machine here was extremely responsive; when R2012b was installed, it was essentially useless as a real product--it took several 10s or seconds for even a help command to execute. I've helped that to where I can now use it enough to respond to queries here with actual test code snippets but it took upgrading the memory or the machine to its maximum to be able to do that and it's still noticeably slower interface than R12. Computation speed is no longer such a terrible issue for me as I've retired from active consulting so don't have "real" datasets of size any longer but the improvements in JIT seem to have kept up for the most part altho there are clear overhead costs with the higher-level data abstractions such as dataset, dynamic named structures, etc. That is likely inevitable and often the convenience does outweigh the performance.

Answer 3

[Nicolas Hofer]

I used: datetick("x",1,"keepticks") to transform the datenumbers in the plot back to actual date format.