site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Apr 24, 2008, at 2:45 AM, Martin Costabel wrote: It is strange that I'm getting 69 while Surf Chen is getting 70 though. -- 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 Surf Chen wrote: The Y2038 bug is the unix stamp time range(1970-2038)? I know that and know what difference of long between 32 and 64. But I think strptime is not relative to this issue,since the struct tm store each date parts in a int or a char*,not like the unix timestamp store as a long. The problem appears not to be the struct tm, but the conversion routine that perhaps somewhere internally uses the type time_t. And the codes works fine on my 32bit debian. Well, on the Mac it only works if you compile for a 64bit architecture. Interesting, I would not have thought that this would be the issue here since I was getting 69 and 1969+69 = 2038, the expected date. As you say, -arch ppc64 makes it work. smime.p7s