[Scilab-users] Simple Date & Time Plotting

[Samuel Gougeon]

Le 20/07/2018 à 15:27, CHEZE David 227480 a écrit :
>
> Hi samuel,
>
> Thank you for your prompt comments, I fully agree that it’s not 
> trivial to have a really nice function with the features you pointed out.
>
> I would find hardly acceptable, from common excel coming users point 
> of view, that Scilab can’t offer at least a raw feature to manage this 
> very common task when processing data with timestamps over weeks, 
> months, years therefore I proposed this raw approach.
>

The problem with proposing an official function in a only raw version is 
that it becomes a commitment.
Then changing it is more difficult because backcompatibility issues must 
be avoided or/and handled.
This is why, to me, it is better to propose such a version on the 
fileexchange, that is more informal.

>
> An extra comments about the function labxdtv:labxdtv uses the 
> automatic x-ticks locations caluclated from datenum values and convert 
> into datevec-Like formats eg YY/MM/DD , MM/DD.hh, DD.hh:mm, hh:mm:ss 
> according to the max span of the level of zoom in the current display.
>
> If the axis is zoomed or the window size changed, call again labxdtv 
> so that it re-graduates this x-axis (according to datenum values) and 
> convert the new x-ticks into appropriate datevec and automatic choice 
> of the format YY/MM/DD , MM/DD.hh, DD.hh:mm, hh:mm:ss according to the 
> max span of the x-axis.
>

My PS meant that there is no equivalence of gcf().resizefcn for zooming. 
So, recalling labxdtv() must be done /intentionnally, by hand,/ after 
zooming or spanning an axes.

>
> In your first comment, I ‘m not sure to get your point about :
>
> mailbox:///C:/Users/Samuel/AppData/Roaming/Thunderbird/Profiles/dm9cexq8.default/Mail/Local%20Folders/_Scilab.sbd/users@?number=97209056&header=quotebody&part=1.1.2&filename=image001.png
>
>   * there should not be any shift 17 => 18 => 19. This means that
>     subticking must be completely customized, with a polyline
>     superimposed to the axis, since it is irregular.
>
> In the above example 17, 18 and 19 are years , not days so it’s rather 
> normal display.
>

My fault! As aa/bb/cc is in french the common format for dd/mm/yy, I 
paid attention only to the first aa/bb, taking them for days/months. 
Beside this misunderstanding, the discussion and remarks remain the 
same: then we could rather expect majors ticks always on 1st of some 
months, and smart subticks accordingly.


> At this level of zoom we have YY/MM/DD but if you manually zoom and 
> change the window size and call again labxdtv() afterwards, you may 
> obtain the following, which allow to see when you :
>
> And zoom-in further around 2017 October, then labxdtv() called you may 
> quickly obtain the figure below, so you can read directly that the 
> format is automatically adapted to “MM/DD.HH”  It’s not so common 
> format but acceptable to analyze the data on the fly.
>

Usual commonly spread formats are quite known and shared.
AFAIK, the most standard one is YYYY-MM-DD HH:MN:SS.ssss, with possible 
truncation.

> .../...
>
> I find quite important that the graduation on the figure is still 
> relying on datenum, as it is the right underlying numerical format to 
> show date time information.
>
IMO, the input format should be customizable though an input option :

  * absolute formats : unix time, julian days, excel time, ... + linear
    (s, days, s..) vs vectorized (datenum, etc)
  * relative formats (without origin) : in s, mn, h, days

Best regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20180720/c6790188/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1708 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20180720/c6790188/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 13922 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20180720/c6790188/attachment-0001.png>