Ah, systemd in fact had tzdata parsing code already – it was used by
tinedatectl to show DST info. Try to recover it from Git.
On Thu, Dec 15, 2016, 21:03 Ran Benita wrote:
> On Thu, Dec 15, 2016 at 06:35:15PM +0100, Lennart Poettering wrote:
> > So yeah, we'd love to support this, but are waiti
On Thu, Dec 15, 2016 at 06:35:15PM +0100, Lennart Poettering wrote:
> So yeah, we'd love to support this, but are waiting for a suitable API.
I see, makes sense.
Since new glibc API will probably be slow to come, if ever, it might
make sense to circumvent it and go for the tzdata directly? It see
On Thu, Dec 15, 2016 at 04:37:19PM +, arnaud gaboury wrote:
> I am still with a broken UID/GID container for some specific directories.
> This is described in issue #4078 [0].
>
> It start to be annoying as I can't upgrade some packages on the Fedora
> container. At least, I think failed upgra
On Thu, 15.12.16 17:52, Ran Benita (ran...@gmail.com) wrote:
> My question: is this not supported on purpose (because timezones suck),
> or because it's just not implemented/hard to implement?
Current systemd actually supports calendar events with timezone
specifications. However, the specified t
I am still with a broken UID/GID container for some specific directories.
This is described in issue #4078 [0].
It start to be annoying as I can't upgrade some packages on the Fedora
container. At least, I think failed upgrades are related to this issue.
Let's take one example:
# dnf upgrade iput
I would like to schedule some timers to execute daily at a given time in
some given timezone. My use-case for this is:
- The server's local timezone is UTC - this is just good practice for
various reasons, so I don't want to change that.
- For business reasons, the service I want to run needs t
