Absolutely. The fact that current BACnet schedules cannot cross
midnight is a glaring omission. Is is common for real people to want
to make schedules that cross midnight, and clever workstations have to
split that desire into two schedules (one ending at 23:59:59.99 and one
starting at 00:00:00.00) and hope to goodness that the target device
crosses midnight without a bump. This is not pretty. All future
changes to the schedule object should handle crossing midnight
Hello Rene, Steve, and other innocent bystanders...
Rene identified an important issue, but I am concerned that we will limit
the usefulness if we do not come up with a mechanism to support offsets
that span the midnight boundary.
In the real world, time is a linear thing, and offsetting something by 4
hours is offsetting it by 4 hours, and the fact that 4 hours earlier
happens to be the day before has no bearing whatsoever on the real world.
Steve Karg <steve@...>
2005-02-16 12:42 PM
Please respond to BACnetLighting
Subject: Re: [BACnetLighting] DMF-028-2 with offset in weekly-schedule
There should probably be additional rules, e.g. that the time can't be
shifted with offest outside the "current day"....
What do you think about that?
There is also the case where sunrise or sunset returns 00:00 (i.e. no
sunrise or sunset) because the device is located in Alaska or another
area of the world where it is sunny or dark 24 hours a day for part of
the year, and there is an offset.
I agree that additional rules, rather than error responses or leaving it
a local matter, would be a good idea. Making it part of the standard
would keep implementations from configuration problems.
Dave Robin, Automated Logic Corporation
icbm: 34°00'17.42"N, 84°35'04.91"W