Since issue #211 is already closed, but the DST topic is not really covered that satisfying (IMHO) yet, it would be sad to see some of the suggestions made in the conversation lost.
I can't see @m-mcgowan's proposal being followed up on
TimeChangeRule usEDT = {"EDT", Second, Sun, Mar, 2, -240}; //UTC - 4 hours
TimeChangeRule usEST = {"EST", First, Sun, Nov, 2, -300}; //UTC - 5 hours
Timezone usEastern(usEDT, usEST);// calls Time.zone(), Time.enableDST(), Time.setDSTOffset() using a DST setting determined from
// the current UTC time and the data in the Timezone instance.
Time.timezone(usEstern);
Also @wgbartley's comment is worth pursuing
https://github.com/spark/firmware/issues/211#issuecomment-223679554
IMO, there is little use in currently available functions
static float getDSTOffset(); // since set by my code, I already know
static void setDSTOffset(float offset); // since my code has to provide that (probably via a #define) what's won?
static void beginDST(); // yup, since my conde needs to call this, I could do the zone math myself
static void endDST(); // ditto
static uint8_t isDST(); // hmm, my code tells you what you should tell me back???
If I have to calculate when to call beginDST() and endDST() and also have to setDSTOffset() in my own code, I don't see any benefit in having these functions.
So the only raison d'锚tre for these would be as basis for automatic switching based on rules.
馃憤 馃憤 馃憤
Hey Particle,
Any further development for this feature? This is basically an essential part of supporting any ioT product with a clock and behavior based on that clock (most products). Currently we're updating a customer's time zone offset or DST offset over the air after the product has been set up. Sadly, that's not a great customer experience due to the manual delay, and also not at all scalable.
What's to stop a Particle device from fetching its own local time and DST value, in the way other devices like a Mac do once gaining access to internet in a new region?
Currently I find the customer's time by
Time.zone(), based on what offset would represent that timeCan we make this feature a priority?
Looking up their last IP using a Particle device API call
That's not really a reliable source especially for cellular devices.
And the physical location doesn't always need to be the same as the desired time zone (e.g. world clocks).
So your proposal will fit most use cases, but not all and hence a universal solution has to be found and the proposed TimeChangeRule approach does seem to be a good one for that.
Totally, i hear you regarding those cases. But for many vanilla WiFi product applications it would be quite helpful!
What if it were more of an opt-in situation, like.
Time.detectCurrentTimeBasedOnGlobalIP(). Then that could potentially set and enable DST, as well as adjust the time zone. The user could test or override those values for their application, and if they wanted to do everything as we currently do, they could simply not call it!
Just thinking here, as there are many ioT devices with this similar problem, and many of them will be on WiFi and not be something like a world clock.
I get the impression that DST hasn't been resolved yet, is that the case? Almost all of my projects have date/time functionality, and since I received my first kickstarter core, they either report an hour off all summer, or I have to flash them with a different time zone. I have been including code to figure out if it's DST, but reporting the time correctly seems to be pretty intrinsic to a device often used for logging and reporting, shouldn't it be part of base code/OS?
my feelings exactly.
Most helpful comment
Totally, i hear you regarding those cases. But for many vanilla WiFi product applications it would be quite helpful!
What if it were more of an opt-in situation, like.
Time.detectCurrentTimeBasedOnGlobalIP(). Then that could potentially set and enable DST, as well as adjust the time zone. The user could test or override those values for their application, and if they wanted to do everything as we currently do, they could simply not call it!Just thinking here, as there are many ioT devices with this similar problem, and many of them will be on WiFi and not be something like a world clock.