[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170610132351.GH30784@example.net>
Date: Sat, 10 Jun 2017 15:23:51 +0200
From: u-uy74@...ey.se
To: musl@...ts.openwall.com
Subject: Re: detect timezone changes by monitoring /etc/localtime
(like glibc)
On Sat, Jun 10, 2017 at 08:23:04AM -0400, Rich Felker wrote:
> On Sat, Jun 10, 2017 at 11:57:09AM +0200, u-uy74@...ey.se wrote:
> >
> > 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.
> > ... 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.
As I see it, the time zone is an application internal business, not a
"computer system" one. Even inside the same running application instance
different presentations may need to account for different time zones,
say if the application serves multiple users concurrently or if it
prepares data for multiple uses going to consume the data (say a report)
in different time zones.
It is not only that the API is badly designed but also the design was
highly misdirected :(
In a sense, an application relying on a "system wide time zone"
can not be expected to work reliably, because there is no well defined
semantics of such a thing. The misperception comes from the time when
computers were stationary and isolated from each other.
> 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.
Yes I believe I see your point. Still the split form of the time
representation looks to me "human-specific" and I can not easily imagine
when it would make sence to handle this kind of representation outside
of a certain time zone context, the latter targeting humans.
Of course a split internal time representation is a possible application
design choice but it is like designing the microcode of a binary CPU to
do all calculations in (irregularly tweaked) sexagecimal. Possible but
hardly justified beyond some very specific niche cases.
My two cents.
Regards,
Rune
BTW thanks for musl!
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
