Feature Request: Have get_local_time() Do Something With UTC Offset

[PaintYourDragon]

The data’s there in the Adafruit IO time response but is currently discarded. This could either be returned by the function (in which case, programs that don’t need it can just ignore) or stored in the class somewhere (requiring a name or getter function and a few bytes of RAM).

This is rare, but some things do want a valid UTC offset…anything using the MET Norway sun/moon API for example (Moon phase clock, LED shadow box), maybe others. The current workaround is to follow a call to get_local_time() with a second “manual” query from Adafruit IO that requests just the UTC string. Doing this once on startup won’t suffice, since it changes twice a year. During the periodic time syncs that a lot of projects do anyway seems preferable.

I’m not too concerned with the representation. Adafruit IO response is a string 'sHHMM' (sign, hours, minutes), MET Norway wants 'sHH:MM', but it’s a trivial conversion, so I’d maybe just keep the original response string (e.g. don’t separate into integer tuple, because reasons).

[makermelissa]

I just created a PR. I took a slightly more open reusable approach. I created a new function that will pass the raw format onto the strftime service. So for your particular use case, you can just call just network.get_strftime("%z").

[PaintYourDragon]

This still requires two server round trips though, doesn’t it? One to set the clock, a second to get the UTC offset. The latter information is already present in the TIME_SERVICE_FORMAT string but goes unused. Seems a shame to get it along with the time, have it ignored, then immediately ask for it again separately. i.e. just moves the bloat out of the application and into the library.

[makermelissa]

Yeah, I see what you mean, especially with having a name like get_local_time(). I was just trying to save you the trouble of having to parse the entire string. I'll throw in a quick pr to just return the entire string then.