Scheduler - When does the day end?

Forgot to mention that i am using daypilot for java. If that matters.

Further investigation leads me to think this might have something to do with Daylight savings time. It appears that the scheduler has defined the start of the day as 0100 when its summertime. And 00:00 when its wintertime. Could this be correct?

I do not store my dates with any timezone information at all in my db. So i do not really care about what timezone we are in. And i dont really care about daylight savings either, since my events operate on a day to day basis, not hourly.

It would be nice if i could have all my dates in db stored as 00:00. And then get the scheduler to use 00:00 as the start and end of a day. Even in the summer. Is this possible?

All date and time calculations are done using DayPilot.Date class which uses the GMT base for all operations. This should eliminate influence of the time zone and daylight saving time.

Questions:

1. What's your timezone?
2. What's the browser you are using?

1. GMT+1 (CET)
2. Firefox 5.0 and IE9. Same thing occurs in both browsers.

Do you not get the same time-differences when you are testing?

I confirm the bug. It happens here as well. It's a strange thing, I'm investigating the issue.

It's now fixed in build 1.0.187. See also: http://java.daypilot.org/daypilot-pro-for-java-1-2/

Thanks for reporting the bug!

Thanks for adressing and solving the matter fast. Thats reassuring!

Hello again. It seems as this fix has created a new bug. Events are no longer shown. I have confirmed that in my DpsServlet the setEvents method is run with the correct data. However the events do not show in the scheduler. It seems as the same has happened to your own sandbox demo. Check it out: http://java.daypilot.org/sandbox/Scheduler/

This should be fixed now in the latest build (1.1.188):

http://java.daypilot.org/daypilot-pro-for-java-1-2/

The JS libraries were updated to the latest version and the backend was not sending the event data in a correct format. Thanks!

13 minutes from reported bug to fixed and ready for download. Impressive!! :)

Hello again. New bug seems to have appeared now. When loading bubble-text i get this javascript error:
$f.root is undefined
http://java.daypilot.org/sandbox/js/daypilot/bubble.js
Line 2

OK. It's fixed now (and two more bugs fixed as well as a bonus).

See build 1.1.189:

http://java.daypilot.org/daypilot-pro-for-java-1-2/

Looking forward to the next bug....

Thanks for your fix.
I have now tested with your latest build and it seems as the original daylight-bug is still there. But i can clearly see that something has been done, so the bug now behaves differently.
I have tried several things, but i cant yet put my finger on exactly what goes wrong. But this is my findings so far:
Still using CET (GMT+1) Thats UTC(zulu)+2 in summer.

1. If i set start and enddate in my db to time 02:00:
During the summermonths (summertime) the bookings start and enddate will display correctly. The colored top will show the bookings as completly filling all days (ie. no small white gap at each end). During wintermonths however, the start will still display correctly, but the end will span into the next day.

2. If i set start and endate to 01:00:
During summer start will span into the day before and end displays almost correct. However it seems as the last hour of the day is not occupied.
During winter start and end is correct and filling entire days.

3. If i set start and enddate to 00:00:
During summer start will span into the day before and end displays almost correct. Seems like the two last hours of the day is not occupied.
During winter start still spans into the day before, and end is almost correct. Seems like end is not filling the last hour of the day.

I cant replicate this on your sandbox demo. Only in my testenvironment. I have double checked i got the latest js files and cleared my cache. Any suggestions?

Oh just thought of something. Might be just me using original javascript date object in my code. I'll check it out and post back.

Nevermind. Thats just for editing and adding new events. The bug appears when loading straight from database. In my event-class i have start and end-date fields as java.util.Date. Could there be a bug when converting from those fields to the org.daypilot.date.DateTime as is used in the Event-class?

DayPilot works with a straight timeline (GMT-like). It assumes all dates are in a single timezone that doesn't observe DST. Internally, it's represented by a GMT date.

You are correct that org.daypilot.date.DateTime doesn't translate an existing java.util.Date correctly - it reads its base using getTime() and then it works with its GMT value. That is necessary in order to get the calculations right. The same is done in DayPilot.Date on the client side.

I will fix that for now so it reads the java.util.Date using its timezone representation. However, this will have to change some day in the future when the timezone layer is added to DayPilot.

Ok. So i'll wait for your fix and try that.
I tried to alter my custom Event-class to use org.daypilot.date.DateTime for start and enddates, but it seems as there are no support for this. I get this funny exception:
java.lang.RuntimeException: Unable to convert from class org.daypilot.date.DateTime to org.daypilot.date.DateTime
This occurs when mapping setDataStartField("myDateTimeFormattedDate");
If i could pass start and enddates as a org.daypilot.date.DateTime object then i could make sure timezone information is discarded.

This is a nice exception, indeed. ;-) Now it supports DateTime properties as well.

I've updated the DateTime class a bit so it can stay consistent for the future. The constructor that creates a new DateTime from a java.util.Date or java.sql.Timestamp instance now has an additional option that forces it to read the local time value from the the input.

This way the internal DateTime value can be consistently considered a GMT time in the future. The default DateTime(Date) constructor will read the value using getTime() as it does now. The new DateTime(Date, boolean) can force it to read the current time zone value instead.

The events reader in DayPilot Scheduler now uses DateTime.parseAsLocal() method (which will read the local time from Date objects). In the future, it will be possible to specify how to handle Date objects.

These changes are available in build 1.1.190.

Great work! Just tried the latest build and now the events are displayed properly if they are stored in my database as time 00:00

I noticed one more thing though. When i am working with a DateTime object, i would need to convert it to a java.util.Date object without timezone-bias. Right now the toDate() method will add 2 hours to my Date object because of the timezone.
Would it be possible to have an extra toDate() method that disregards timezone information?

I've added DateTime.toDateLocal() method that returns the Date as a local date. It can be used to pass the data to the database.

See build 1.1.191:

http://java.daypilot.org/daypilot-pro-for-java-1-2/

Thanks Dan! I'll try the new build in a bit and post any errors if they occur. A really appriciate your quick responses and fixes!