Possible BUG in v4.0 when using limit.js and addMarkedTS?

Hy there,

I’m currently migrating from v3.6 to v4.0. Everything was smooth sailing till I noticed that my marked times are not rendered as they should.

In 3.6 the offset for the marked times started with the value given for ‘x_start’ in the ‘createTimelineView’ while in 4.0 it always starts at 12:00 am (midnight). Please see attached images.

Marked times in v3.6:
[480,540] → mark times 480 min from start-hour (8 a.m.) till 540 min from start → block = 16-17 p.m.


Marked times in v4.0:
[480,540] → mark times 480 min from start-hour (12 midnight) till 540 min from start → block = midnight-8 a.m.


The example shown in the image uses this set-up:

[code]// TL init
scheduler.createTimelineView({
name: “timeline_D”,
x_unit: “minute”,
x_date: “%H:%i”,
x_step: 30,
// x_size: 24, // LIVE
x_size: 48, // TEST
x_start: 16,
x_length: 48,
y_property: “section_id”,
y_unit:treeYachsis,
render:“tree”,
section_autoheight: false,
dy: 30
});

// set blocks
var config = {
days: [1,2,3,4,5],
zones: [480,540],
invert_zones: false,
css: opts.color,
type: “default”,
sections: {timeline_D: parseInt(opts.id, 10),
timeline_W: parseInt(opts.id, 10), // other TL-view
timeline_M: parseInt(opts.id, 10)} // yet another TL-view
};
scheduler.addMarkedTimespan(config);[/code]

Could it be that this is related to the new functionality of Hiding Time Units in the X-Axis of a View which is now used to set/determine the offset for blocked times!? Just guessing.
Maybe I’ve done something wrong but if so, I’m not able to find the cause.

For now I can use the limit.js from v3.6 as fallback but I don’t think that is clean so any insight/help/answer is highly appreciated!

Thanks in advance
Simon

The behavior in fact does differ between 3.6 and 4.0, but it was a fix not a regression.
The zones configuration option do work as absolute time shift starting from the start of day, otherwise the same marker may be placed at different time areas because of different time start in different views. It was designed in such way initially, and x_start processing in version 3.6 was a bug.

If necessary I can provide a patch for 4.0 which will revert the previos behavior, but all next version will have the current behavior ( zone starts from the midnight, not from x_start )

Sorry, we have forgot to include info about this update in migration documentation.

Hy Stanislav,
thank you for clearifying!

If this behaviour is intended I’ll use it as is and just adapt my code. Your explanation about the timeshift was also very clear and is reason enough to change it on my side rather than on yours.

The missing info in the migration guide is no problem, too, because your forum response times are as quick as hell :smiley: .
(But it also wouldn’t harm to add this piece of information :wink: )

Thanks a lot and have a nice day!
Simon