site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Apr 25, 2008, at 2:46 AM, Surf Chen wrote: The code I posted above is work fine on 32 bit linux box(of cource with 32-bit c std lib). The time_t on my 32 bit linux box is 32 bits(sizeof(time_t)==4),but the y2038 bug not raised.So can I say the GNU version strptime DO NOT use time_t during the parsing? You should probably say "does not." But the code not works on my 32bit mac osx,so can I say the darwin implementation of strptime DO use time_t during the parsing? And again here, "strptime does use..." And If I want to make the code works correctly on my 32bit mac osx,I should write my own code to implement? Unfortunately, it seems like that is your only choice. Can you all use simple English when reply?I get puzzled when come with too complicate senctence.. Here I came with one:(I am so sorry for my bad English ability) Don't worry, your English is quite good. -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com Personally, I don't think it is reasonable to have such a restriction. We shouldn't be pretending that time after 2038 doesn't exist and struct tm shouldn't have those requirements at all. (In fact, it makes very little sense to have the year start at 1900. It could very easily start at 0 and have 2008 really mean 2008, stupid standards.) The int for the year is more than big enough to handle 2038 or 20380. Using time_t internally for strptime makes no sense at all (from an outsider's perspective). There is already something in place to handle failure of mktime() to convert from struct tm to time_t, namely returning -1. The limitations of struct tm shouldn't carry over to struct tm (and they clearly don't have to as running the code on Linux shows). I recommend you file a bug report <http://bugreport.apple.com>. smime.p7s