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.