Time units and functions
Hi all, firstly, it seems we are using a bunch of time functions that are not thread-safe (localtime gmtime and asctime) (See recommendation here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/sy...) - so I'll push up a p/r for that. Next is the couple of Metrics that are using the unit 'Seconds' but which are really time_t values.. I'm looking to add a new Group of metrics for time with units UnixEpoch, UTCDate & LocalDate. This is what I have at the moment with the default metrics for m.time.utc as UTCDate and v.p.gpstime as LocalDate. (I can make them the same) m.time.utc 2023-10-19 11:22:28 UTC v.p.gpstime 2023-10-19 19:22:26 AWST Currently I've changed these in the JSON to be exported as "%FT%T.000Z" which is a semi standard for JSON. The 'conversion' for the date values doesn't do anything - these really only effect the output. I've also been looking at v.g.timerstart which is UTCTime & LocalTime units. I've fixed up conversions both way.. v.g.timerstart 18:00:00local Thoughts on these? Cautions? //.ichael
Michael, Am 20.10.23 um 07:02 schrieb Michael Geddes:
Hi all,
firstly, it seems we are using a bunch of time functions that are not thread-safe (localtime gmtime and asctime) (See recommendation here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/sy...) - so I'll push up a p/r for that.
I don't see which recommendation you refer to on that page, but you're right, we shouldn't use these unsafe calls. The correct way to avoid concurrency issues is to use the "_r" versions of these, i.e. "localtime_r" etc. -- these are included in newlib.
Next is the couple of Metrics that are using the unit 'Seconds' but which are really time_t values.. I'm looking to add a new Group of metrics for time with units UnixEpoch, UTCDate & LocalDate. This is what I have at the moment with the default metrics for m.time.utc as UTCDate and v.p.gpstime as LocalDate. (I can make them the same)
m.time.utc 2023-10-19 11:22:28 UTC v.p.gpstime 2023-10-19 19:22:26 AWST
Currently I've changed these in the JSON to be exported as "%FT%T.000Z" which is a semi standard for JSON.
The 'conversion' for the date values doesn't do anything - these really only effect the output.
I've also been looking at v.g.timerstart which is UTCTime & LocalTime units. I've fixed up conversions both way.. v.g.timerstart 18:00:00local
Thoughts on these? Cautions?
As long as the current uses won't be affected (shouldn't, as they use AsInt()), I think that will be fine. Btw, v.c.timerstart is the pendant for the charge timer. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, BTW I've since added AsString() implementation for both the LocalTime, UTCTime, and LocalDate and UTCDate. The Date values need to be the format yyyy-mm-ddThh:nn:ss - ie 2023-02-20T13:01:00 I figured that would be the easiest to avoid having a space in the value! Also more inline below: //.ichael On Sat, 21 Oct 2023 at 14:39, Michael Balzer <dexter@expeedo.de> wrote:
Michael,
Am 20.10.23 um 07:02 schrieb Michael Geddes:
Hi all,
firstly, it seems we are using a bunch of time functions that are not thread-safe (localtime gmtime and asctime) (See recommendation here:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/sy...)
- so I'll push up a p/r for that.
I don't see which recommendation you refer to on that page, but you're right, we shouldn't use these unsafe calls. The correct way to avoid concurrency issues is to use the "_r" versions of these, i.e. "localtime_r" etc. -- these are included in newlib.
It's in the section 'Get Current Time' as a code snippet, however yes, I'm using the _r versions of the functions.
Next is the couple of Metrics that are using the unit 'Seconds' but which are really time_t values.. I'm looking to add a new Group of metrics for time with units UnixEpoch, UTCDate & LocalDate. This is what I have at the moment with the default metrics for m.time.utc as UTCDate and v.p.gpstime as LocalDate. (I can make them the same)
m.time.utc 2023-10-19 11:22:28 UTC v.p.gpstime 2023-10-19 19:22:26 AWST
Currently I've changed these in the JSON to be exported as "%FT%T.000Z" which is a semi standard for JSON.
The 'conversion' for the date values doesn't do anything - these really only effect the output.
I've also been looking at v.g.timerstart which is UTCTime & LocalTime units. I've fixed up conversions both way.. v.g.timerstart 18:00:00local
Thoughts on these? Cautions?
As long as the current uses won't be affected (shouldn't, as they use AsInt()), I think that will be fine.
Yeah, as for as the code goes they are still integers. At the moment the main change is that I have m.time.utc default to UTCTime unit (rather than UnixEpoch) and v.p.gpstime default to LocalTime. This will mean changes to the user interface and scripting interface for those values. I'm ok with leaving it like that or I could just default to UnixEpoch.
Btw, v.c.timerstart is the pendant for the charge timer.
AH yeah, I worked that bit out. I initially though UTCTime was for a time_t value but I twigged to where that value was coming from and what that meant.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (2)
-
Michael Balzer -
Michael Geddes