site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks to the useful replies here. But I need to ask a final question:On Mac OSX and with 32 bit compile option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or other structs like that? Do I need to down or write an alternative lib to parse it? You don't, it's out of range. WORKING-STORAGE SECTION. 01 DATE-FIELD. 05 DAY PIC 99 VALUE ZEROS. 05 MONTH PIC 99 VALUE ZEROS. 05 YEAR PIC 99 VALUE ZEROS. <http://en.wikipedia.org/wiki/Year_2038_problem> I don't want to mix different quetions here,just want to make sure that I should forsake strptime right now. -- Terry _______________________________________________ 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... On Apr 25, 2008, at 12:10 AM, Surf Chen wrote: That's why it's called "The UNIX Y2038 bug". Just like all those COBOL programs that had "The Y2K bug" in the way they handled dates, e.g.: ...years with values outside the range 00-99 were simply out of range and impossible to represent in memory. That's why there was a lot of money parsing COBOL code into a data dictionary, identifying this type of issue, and emitting refactored COBOL source code without the bug. As we approach Y2038, I expect there will be a lot of UNIX jobs doing the same thing for Epoch-based dates. See: I expect most code will be 64 bit by then, and then we'll be safe until we hit "The Y290G bug". I could go into gory details on what portable code can and cannot expect from a UNIX compliant host OS, but short of writing your own code to do the parsing and storing the date as a string, you simply aren't going to be able to do this portably. This email sent to site_archiver@lists.apple.com