Re: strptime cannot parse date older than 1938
Re: strptime cannot parse date older than 1938
- Subject: Re: strptime cannot parse date older than 1938
- From: "Surf Chen" <email@hidden>
- Date: Fri, 25 Apr 2008 17:46:44 +0800
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?
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 If I want to make the code works correctly on my 32bit mac osx,I
should write my own code to implement?
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)
On Fri, Apr 25, 2008 at 4:34 PM, Terry Lambert <email@hidden> wrote:
>.....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.
On Fri, Apr 25, 2008 at 4:34 PM, Terry Lambert <email@hidden> wrote:
> On Apr 25, 2008, at 12:10 AM, Surf Chen wrote:
>
> > 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.
>
> 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.:
>
> WORKING-STORAGE SECTION.
> 01 DATE-FIELD.
> 05 DAY PIC 99 VALUE ZEROS.
> 05 MONTH PIC 99 VALUE ZEROS.
> 05 YEAR PIC 99 VALUE ZEROS.
>
> ...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:
>
> <http://en.wikipedia.org/wiki/Year_2038_problem>
>
> I expect most code will be 64 bit by then, and then we'll be safe until we
> hit "The Y290G bug".
>
>
>
>
> > I don't want to mix different quetions here,just want to make sure
> > that I should forsake strptime right now.
> >
>
> 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.
>
> -- Terry
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden