With a little leave time around XMas and a flight back to Canada, I had a bit more time to play around with Rust, and managed to fix an irksome timezone bug that was plaguing habitctl, the minimalist habit tracker CLI.
I’m really enjoying coding in Rust. As a language, I find it makes sense, is performant, and its prescient compiler checking on types and such makes it hard to shoot yourself in the face.
My last trip abroad, I noticed as soon as you crossed a dateline from your original destination, the use of a timezone aware Date type in habitctl would mess up the tracker from the prompt and recording/logging perspective. Everyone wants a day-by-day logging of their habits even if say, one day ends up being more than 24 hours due to long-haul flight travel (conversely, this makes you have to squidge a bit on flights back around the globe.). I’m kinda sure this is more a “me” problem than for most people using the app, but an inadvertant side effect from the original implementation.
Luckily, the existing chrono crate library used in the original implementation has a nice
NaiveDate type which removes (with a little re-work) the timezone element of the Date structs in the program and convert things like
Local::date().now() to the (not entirely obvious)
Local::today().naive_local() to make sure you don’t have type conflicts when you compile.
More importantly, tha changes fix the CLI so it operates normally even if you change global locations.
The original author seems to not be responding to (numerous) pull requests on habitctl, so I’ve bumped the version on my personal repo and will make another pull request though at this point, I feel I’ve now forked the app and have somehow taken over development/maintenance (and have to admit am toying with the idea of redeveloping it in Crystal for the experience and ease of future features.).
Merry Christmas to everyone using the tracker! Hopefully I’m not the only person who needed this bug fixed.