Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!auspex-gw!guy From: guy@Auspex.COM (Guy Harris) Newsgroups: comp.unix.bsd Subject: Re: Where is strptime? Message-ID: <18742@auspex-gw.auspex.com> Date: 23 Oct 93 21:51:49 GMT References: <CF92Hw.EB8@sybase.com> Sender: news@auspex-gw.auspex.com Organization: Auspex Systems, Santa Clara Lines: 43 Nntp-Posting-Host: bootme.auspex.com >strptime (converse of strftime) exists in SunOS 4.*, and I had thought >it was a BSD funtion, but I can't find it anywhere in the BSD sources. That's because it *isn't* in the BSD sources; I cooked it up for SunOS 4.1. I don't think that, in the form I wrote it, it's the right solution to the problem; it's gone beyond "smart" to "smart-ass". It has the notion that certain format fields are optional, so that you don't have to put in, say, the seconds field (or minutes field) of a time, or the year field of a date; that's a bit of a hack (and took a bit of work to get right). As such, I'm glad I didn't get Sun to donate it to Berkeley, say, and would prefer that people *not* attempt to re-implement it as it stands. Instead, I think the scheme used by SVR4's "getdate()" is somewhat better - have a list of date formats, and try them one after the other. Some would have the "optional" format fields, and others wouldn't. Another possibility, at least for OSes that have run-time dynamic loading mechanisms, would be to use Steve Bellovin-style "getdate()" routines (his has a YACC grammar that lets you use a wide variety of date/time formats - I think it accepts, for example, "tomorrow" as a date), and have different versions of it loaded up depending on the setting of the LANG environment variable, so that you aren't stuck with, say, US-style date/time formats. In either case, the routine should: 1) generate a "struct tm", as SVR4's "getdate()" does, not generate a "time_t", as Bellovin's "getdate()" does - "mktime()" (which, alas, didn't exist when Bellovin did his "getdate()") should be used to generate "time_t"s; 2) have its choice of date/time formats governed by the setting of the LANG (and possibly LC_TIME) environment variables, so that you don't have to muck with, say, the DATEMSK environment variable, as SVR4's "getdate()" appears to require (LANG and/or LC_TIME will affect the month and weekday names SVR4's "getdate()" accepts, but, as I remember, it does *not*, for example, affect whether it accepts MM/DD/YY or DD/MM/YY).