src-test2/lib/libc/stdtime/localtime.c, branch release/8.1.0_cvsFreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=release%2F8.1.0_cvs2010-07-17T05:41:01ZCopy releng/8.1 to release/8.1.0 for 8.1-RELEASE.2010-07-17T05:41:01ZKen Smithkensmith@FreeBSD.org2010-07-17T05:41:01Zurn:sha1:90d6fa76a8141fc596ad376ecd86a8a493836298
Approved by: re (implicit)
This commit was manufactured to restore the state of the 8.1-RELEASE image.
MFC 199607, 200797, 201270, 201669:2010-01-13T18:12:21ZJohn Baldwinjhb@FreeBSD.org2010-01-13T18:12:21Zurn:sha1:8e42544da718ea0ba64994213aa5b4d02771bc3e
Use pthread_once() to initialize the thread-local storage for localtime()
and gmtime() and _once() to initialize gmt state rather than home-rolled
versions using pthread mutex locks.
MFCs of r197764, r197765, r197766, r197847:2009-10-31T06:35:40ZEdwin Groothuisedwin@FreeBSD.org2009-10-31T06:35:40Zurn:sha1:05edd60be4d7d6ca84139790e90a061945904cd3
Modified locale(1) to be able to show the altmon_X fields and the
[cxX]_fmt's. Also modify the "-k list" option to display only
fields with a certain prefix.
Add the comment "(FreeBSD only)" to the altmonth_x keywords
Remove duplicate if-statement on gmt_is_set in gmtsub().2009-06-23T22:28:44ZEdwin Groothuisedwin@FreeBSD.org2009-06-23T22:28:44Zurn:sha1:9cf330555af80a6578384b84bcc2c0fa6d11a641
MFC after: 1 week
MFV of tzcode2009e:2009-05-23T06:31:50ZEdwin Groothuisedwin@FreeBSD.org2009-05-23T06:31:50Zurn:sha1:dfc79e892f85abf6795318009680a31a8813109c
Upgrade of the tzcode from 2004a to 2009e.
Changes are numerous, but include...
- New format of the output of zic, which supports both 32 and 64
bit time_t formats.
- zdump on 64 bit platforms will actually produce some output instead
of doing nothing for a looooooooong time.
- linux_base-fX, with X >= at least 8, will work without problems related
to the local time again.
The original patch, based on the 2008e, has been running for a long
time on both my laptop and desktop machine and have been tested by
other people.
After the installation of this code and the running of zic(8), you
need to run tzsetup(8) again to install the new datafile.
Approved by: wollman@ for usr.sbin/zic
MFC after: 1 month
Normally, we are often reading local time rather than setting time zone,2008-04-01T06:56:11ZDavid Xudavidxu@FreeBSD.org2008-04-01T06:56:11Zurn:sha1:ad4a96ba1372dfc2ebe55792528e9136212a6c95
replace mutex with rwlock, this should eliminate lock contention in
most cases.
Reduce lock contention for simple cases.2007-12-19T04:30:10ZWarner Loshimp@FreeBSD.org2007-12-19T04:30:10Zurn:sha1:9227047ec5d0ee611c6c0a41f85474a00fd83266
# this really should be done with pthread_once, but I've debugged this code.
Reviewed by: arch@
On FreeBSD/arm, any value > 50 bits will result in a rediculously huge2007-01-19T01:16:35ZWarner Loshimp@FreeBSD.org2007-01-19T01:16:35Zurn:sha1:9685457382383fda97d84adcdbcb857cfc497614
number being returned for mktime and timegm calls. Choose 48 because
that works well. This does reduce the dynamic range of tm_year from
about 2 billion years down to "only" about 9 million years. Please
contact me if this restriction poses a problem.
Due to the complexity of the code, I admit that I didn't trace down
what, exactly, was overflowing with longer bits. This fixes software
that we run on the embedded systems we have.
struct tm.tm_year is listed as 'years since 1900', and is signed. On2004-08-24T00:15:37ZPeter Wemmpeter@FreeBSD.org2004-08-24T00:15:37Zurn:sha1:ee4dc2a402382866ff0b8e66da867bbd6609304e
64 bit systems, years roughly -2^31 through 2^31 can be represented in
time_t without any trouble. 32 bit time_t systems only range from
roughly 1902 through 2038. As a consequence, none of the date munging
code for all the various calendar tweaks before then is present. There
are other problems including the fact that there was no 'year zero' and
so on. So rather than get excited about trying to figure out when the
calendar jumped by two weeks etc, simply disallow negative (ie: prior to
1900) years.
This happens to have an important side effect. If you bzero a 'struct
tm', it corresponds to 'Jan 0, 1900, 00:00 GMT'. This happens to be
representable (after canonification) in 64 bit time_t space. Zero tm
structs are generally an error and mktime normally returns -1 for them.
Interestingly, it tries to canonify the 'jan 0' to 'dec 31, 1899', ie:
year -1. This conveniently trips the negative year test above, which
means we can trivially detect the null 'tm' struct.
This actually tripped up code at work. :-/ (Don't ask)
Merge changes from the tzcode2004a import. Wherever possible I tried to bring2004-06-14T10:31:52ZStefan Farfelederstefanf@FreeBSD.org2004-06-14T10:31:52Zurn:sha1:cdff05fa7fa9249256b3ee2ab6722c5e9d6aa000
us closer to the vendor branch.
Requested by: wollman