Hacksore / bluelinky

An unofficial nodejs API wrapper for Hyundai bluelink and Kia UVO
https://bluelinky.readme.io
MIT License
337 stars 76 forks source link

Time zone always assumed as UTC #281

Closed olithissen closed 3 months ago

olithissen commented 3 months ago

Various API methods return timestamps, like start and end in the tripInfo hierarchy for example. For tripInfo these values are parsed manually and converted to a JS Date. The Date constructor always assumes UTC as time zone while the API itself probably delivers no time zone information at all. (I assume they are all local times based on the car settings)

I'm in the Europe/Berlin TZ so if my trip starts on 2024-06-17 at 09:22, the parse result is 2024-06-17T09:22:00Z which is two hours off due to time zone and current DST. It should actually be either 2024-06-17T07:22:00Z or 2024-06-17T09:22:00Z+02:00. If you just need to display the information this is not a big deal, but if you do any time based analyses or correlations in a database the offsets get quite cumbersome.

My current workaround involves using a lot of client-side moment.js to force time zone conversions on the Date before further processing it.

Can we think of anything to provide an optional time zone in Bluelinky directly? (This would still be a bit wonky if you cross time zones...)

All the best Oli

Context

Hacksore commented 3 months ago

JS timezones are always the worst 😂!

I'm not sure I'd want to support that in the lib but feel free to share your finding/code here for others.