added timezone support #34
Conversation
added simple tests updated README.md
|
Linux test passed Ubuntu 22.04 gcc-11.4.0 Windows took quite long to setup with libcurl and openssl. Looks like date-tz from date on windows uses 7-Zip to unpack the received tar ball, so it's not really straightforward using it on Windows. |
README.md
Outdated
|
|
||
| Using TzClock has the following side effects: | ||
| 1. Date requires linkage to `libcurl` | ||
| 2. First time TzClocks timezone lookup will occur it will download the most up to date timezone: "~/Downloads/tzdata" ("%homedrive%\%homepath%\downloads\tzdata" on Windows). |
There was a problem hiding this comment.
I'm thinking this won't work when the library is used as a Windows service as there's no home folder for the LOCALSYSTEM account. Can the download location be passed in to TzClock somehow so that the application can determine where it is downloaded? Also, what about an embedded version of the TZ database?
There was a problem hiding this comment.
I will have a look on Sunday if anything of the following will be possible. Setting database install path will be possible out of the box from date-tz but only at build time trough -DINSTALL=/some/path. I'm sure embedded is possible but would require a good amount of work, like different platform support (Arduino, ESP-IDF, Micro-python, Rust), either embedding db into flash at compile time or using Eeprom at runtime to store latest db, if you are targeting microcontrollers. I don't think I will have time doing all of this.
|
I think we can stick to PC for now, no need to do something no one has asked for.
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Philemon Benner ***@***.***>
Sent: Thursday, February 22, 2024 9:48:07 PM
To: PerMalmberg/libcron ***@***.***>
Cc: Per Malmberg ***@***.***>; Comment ***@***.***>
Subject: Re: [PerMalmberg/libcron] added timezone support (PR #34)
@BestITUserEUW commented on this pull request.
________________________________
In README.md<#34 (comment)>:
+```
+Cron<TzClock> cron;
+if(cron.get_clock().set_time_zone("Africa/Maputo"))
+ std::cout << "Successfully set timezone to: Africa/Maputo \n";
+else
+ std::cout << "Failed to set timezone to: Africa/Maputo \n";
+```
+
+`libcron::TzClock` behaves like `libcron::UTCClock` if no timezone is set.
+
+If you want to use TzClock you have to set -DLIBCRON_BUILD_TZ_CLOCK=ON when building libcron. TzClock is a fully optional feature
+if you don't enable it, it won't be build at all.
+
+Using TzClock has the following side effects:
+ 1. Date requires linkage to `libcurl`
+ 2. First time TzClocks timezone lookup will occur it will download the most up to date timezone: "~/Downloads/tzdata" ("%homedrive%\%homepath%\downloads\tzdata" on Windows).
I will have a look on Sunday if anything of the following will be possible. Setting database install path will be possible out of the box from date-tz but only at build time trough -DINSTALL=/some/path. I'm sure embedded is possible but would require a good amount of work, like different platform support (Arduino, ESP-IDF, Micro-python, Rust), either embedding db into flash at compile time or using Eeprom at runtime to store latest db, if you are targeting microcontrollers. I don't think I will have time doing all of this.
|
moved date-tz build to libcron added LIBCRON_MANUAL_TZ_DB option updated README.md added documentation on how to set install path
|
Windows build is not working yet |
|
|
||
| [More Info about date-tz](https://howardhinnant.github.io/date/tz.html) | ||
| Setting database path / install path can be done with `date::set_install`. If not set path will default to: "~/Downloads/tzdata" ("%homedrive%\%homepath%\downloads\tzdata" on Windows). | ||
| Using TzClock without LIBCRON_MANUAL_TZ_DB requires liburl installed in your system. On Windows it will also require 7-Zip installed into the default location. |
There was a problem hiding this comment.
Wait, it requires 7-zip ? Meaning it will execute it to unpack? I'll have to pull the emergency break here. This library should not execute any application, too much of a security issue the user of this library doesn't have control over.
With that in mind, we'll have to settle with using a pre-existing DB and let the library user handle management of that file.
There was a problem hiding this comment.
With that in mind, the TzClock can take a path to the DB as a constructor argument and call date:set_install, ensuring it is available before the construction of the clock.
|
Closing this stale PR. |
added simple tests
updated README.md