Include sunrise sunset. about time HOT 5 CLOSED

If you are not interested, close this proposal.
I hate to outstanding issues unanswered.

Thank you.

from time.

I would be pleased if someone wanted to create a companion library that supported these functions that worked with the time library. However, this functionality would not be required by most users so I would prefer not to have this code added directly to time.cpp.

from time.

Micheal, eventually (probably mid-2015 time frame) I'd like to consider making Time 2.0. Of course, backwards compatibility must be the overriding design goal for any new version, but I believe there's quite a lot of opportunity for compatible improvements.

From an API point of view, I want to keep Time.cpp as it is today. New stuff should go into separate .cpp files with C++ object APIs. But long-term, as the number of Arduino libraries keeps growing, I believe we'd serve end users much better by offering a single Time 2.0 library with lots of features. It just needs to be designed so all the "extra" stuff is separate .cpp files with their own objects, which are only used if the user creates an instance of the object in their sketch.

However, there is one Time.cpp change I have my eye on. Are you sitting down? Really, this shouldn't be very earth-shattering....

The one thing that's really confusing about Time 1.x is the using a RTC as the sync provider. The sync provider function makes perfect sense for GPS & NTP, where you'd intuitively expect that Time is using the Arduino hardware to keep the date/time and sync periodically with an external reference. But when a RTC chip present or a RTC is built-in (as is likely to become common on more chips over the next several years), having 2 different clocks is confusing.

I still don't have a fully fleshed-out plan, but my gut feeling is something along the lines of defining a C++ base class for RTCs. Maybe the Arduino devs would put it Arduino's core lib, like they do for network client & server, or maybe inside the library is fine? Probably the least intrusive API change could involve a 2nd C++ setSyncProvider() call, which takes a reference to the base class. Legacy code could still pass a plain function, due to C++ overloading, and from a documentation point of view, the API would remain basically the same, but 2 different things you could give to setSyncProvider(). Of course, when given a RTC-based sync provider, the library would either use the RTC directly or keep its count in tight lock-step with the RTC. The sync interval function would become a no-operation when the sync provider is a RTC-based object, but of course it would continue working as documented when using a non-RTC sync provider object, or the 1.0 simple callback function.

I know this is a lot to consider. I'm thinking 2015, probably after San Mateo Maker Faire. But eventually, I do want to support the common user's mental model "I went to the trouble of hooking up a RTC chip, so of course I want it to use the RTC", and I'd like to roll in quite a lot of these other functions like time zones at C++ objects that are separate from the core Time.cpp functions, and don't take any resource if not used, but come as part of a single Time 2.0 library.

from time.

Paul,
thanks for your thoughtful comments.
I can see the benefit of having extra
features easily available but want to
ensure that users of the core functionality are not intimidated by lots of
specialist functions and that the interface can be simple and consistant across all
supported hardware. It won’t be
easy but I expect this can be addressed by good design, documentation and
careful structuring of the code with all the extra stuff in separate files.

I agree
that the current sync provider mechanism is not ideal when an accurate internal
RTC is available. The sync provider mechanism was created to avoid the need to
be constantly sending I2C or serial requests to an external RTC in sketches that
poll the now() function. I will be happy
to work with you on improvements that work better with the latest chips with internal
RTC.

Providing a
rich set of time related capabilities (alarms, time zones etc) with a consistent
interface that works with or without hardware support is a big challenge but it
is well worth doing and I look forward to working with you on this in 2015.
Michael
Date: Thu, 30 Oct 2014 11:40:42 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [Time] Include sunrise sunset. (#3)

Micheal, eventually (probably mid-2015 time frame) I'd like to consider making Time 2.0. Of course, backwards compatibility must be the overriding design goal for any new version, but I believe there's quite a lot of opportunity for compatible improvements.

From an API point of view, I want to keep Time.cpp as it is today. New stuff should go into separate .cpp files with C++ object APIs. But long-term, as the number of Arduino libraries keeps growing, I believe we'd serve end users much better by offering a single Time 2.0 library with lots of features. It just needs to be designed so all the "extra" stuff is separate .cpp files with their own objects, which are only used if the user creates an instance of the object in their sketch.

However, there is one Time.cpp change I have my eye on. Are you sitting down? Really, this shouldn't be very earth-shattering....

The one thing that's really confusing about Time 1.x is the using a RTC as the sync provider. The sync provider function makes perfect sense for GPS & NTP, where you'd intuitively expect that Time is using the Arduino hardware to keep the date/time and sync periodically with an external reference. But when a RTC chip present or a RTC is built-in (as is likely to become common on more chips over the next several years), having 2 different clocks is confusing.

I still don't have a fully fleshed-out plan, but my gut feeling is something along the lines of defining a C++ base class for RTCs. Maybe the Arduino devs would put it Arduino's core lib, like they do for network client & server, or maybe inside the library is fine? Probably the least intrusive API change could involve a 2nd C++ setSyncProvider() call, which takes a reference to the base class. Legacy code could still pass a plain function, due to C++ overloading, and from a documentation point of view, the API would remain basically the same, but 2 different things you could give to setSyncProvider(). Of course, when given a RTC-based sync provider, the library would either use the RTC directly or keep its count in tight lock-step with the RTC.

I know this is a lot to consider. I'm thinking 2015, probably after San Mateo Maker Faire. But eventually, I do want to support the common user's mental model "I went to the trouble of hooking up a RTC chip, so of course I want it to use the RTC", and I'd like to roll in quite a lot of these other functions like time zones at C++ objects that are separate from the core Time.cpp functions, and don't take any resource if not used, but come as part of a single Time 2.0 library.

—
Reply to this email directly or view it on GitHub. =

from time.

Old

from time.