Is it actually possible to use datetick?

12 views (last 30 days)
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.
  1 Comment
dpb
dpb on 15 Oct 2014
Edited: dpb on 15 Oct 2014
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.

Sign in to comment.

Accepted Answer

Sean de Wolski
Sean de Wolski on 15 Oct 2014
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.
  5 Comments
dpb
dpb on 16 Oct 2014
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
Iain on 16 Oct 2014
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.

Sign in to comment.

More Answers (2)

dpb
dpb on 15 Oct 2014
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.
  4 Comments
Peter Perkins
Peter Perkins on 16 Dec 2014
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
dpb on 16 Dec 2014
Edited: dpb on 18 Dec 2014
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.

Sign in to comment.


Nicolas Hofer
Nicolas Hofer on 7 Oct 2021
I used: datetick("x",1,"keepticks") to transform the datenumbers in the plot back to actual date format.

Categories

Find more on Dates and Time in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!