Ken Moffat wrote: > On Fri, Aug 17, 2012 at 11:42:26AM +0300, Markku Pesonen wrote: >> >> I think the problem may lie in the way LFS installs the tzdata package. >> Glibc 2.15 (and earlier) installed timezone data without leap second >> information in /usr/share/zoneinfo and /usr/share/zoneinfo/posix (why >> two copies of the same data, I don't know). Timezone data with leap >> seconds was installed in /usr/share/zoneinfo/right. At least Debian >> seems to do it that way too. LFS only installs timezone data with leap >> seconds in /usr/share/zoneinfo. >> > Thanks for the pointer. I noticed the following in glibc's > Makeconfig yesterday, but because glibc-2.15 had the same, I was > none the wiser : > > # What to use for leap second specifications in compiling the > # default > # timezone files. Set this to `/dev/null' for no leap second > # handling as > # 1003.1 requires, or to `leapseconds' for proper leap second > # handling. > # Both zone flavors are always available as `posix/ZONE' and > # `right/ZONE'. > # This variable determines the default: if it's `/dev/null', > # ZONE==posix/ZONE; if it's `leapseconds', ZONE==right/ZONE. > ifndef leapseconds > leapseconds = /dev/null > endif > > I'll take a look at how debian do things.
On a fresh LFS svn system, I can do $ TZ=EST date;date;date -u Thu Aug 16 23:56:26 EST 2012 Fri Aug 17 04:56:26 GMT 2012 Fri Aug 17 04:56:51 UTC 2012 My understanding is that POSIX ignores leap seconds, and TZ settings does not. The above seems correct to me, but I'm not 100% sure. The above is with a /etc/localtime setting of '/usr/share/zoneinfo/GMT' -> '/etc/localtime'. Without that, the 'date' command reverts to UTC. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
