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: Steve Checkoway <email@hidden>
- Date: Fri, 25 Apr 2008 03:11:06 -0700
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.
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>.
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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