Re: detect timezone changes by monitoring /etc/localtime (like glibc)

[Rich Felker <dalias@libc.org>]

On Sat, Jun 10, 2017 at 11:57:09AM +0200, u-uy74@aetey.se wrote:
> On Fri, Jun 09, 2017 at 10:36:29PM -0500, A. Wilcox wrote:
> > Fun and true facts: this has actually revealed itself as a horrible
> > behaviour in Pidgin.  When I moved from the east coast to the central
> > US, I woke up my laptop and changed the TZ.  It was running a glibc
> > Linux at that point.  Pidgin wouldn't make noise or show notifications
> > until an hour went by; some internal counter had a local time_t and it
> > thought it was receiving old notifications (since the timezone shifted
> > backwards an hour).
> 
> To me it looks like an application [design] bug. Time itself does
> not shift because you are moving to a different angle from the sun,
> so deciding "new" vs "old" should not be concerned with timezones or
> "local time" at all.
> 
> It is the _presentation to humans_ which may need to show
> the "local time" but there is no reason to use it for timekeeping.
> Moreover, there are good reasons to avoid such use.
> 
> > So this isn't a theoretical problem.  It's a very real one.  (And one
> > I have yet to experience running musl Linux on my laptop now.)
> 
> Yes, a real problem, but outside libc, imho.

It's a library issue because, if the invariance of timezone when the
application doesn't intentionally change it is violated on the libc
side, there's no way for applications to meaningfully perform these
kinds of relative operations on local times -- the API is deficient. I
agree the pidgin thing sounds like a pidgin bug (wrongly working with
local times) but there are situations where you need to, or where
you'd prefer to be working in UTC but due to lack of timegm in
standard C, a roundabout route through localtime/mktime and adjustment
for localtime is the only portable solution that's possible.

Rich