On Tue, Nov 14, 2006 at 12:12:23AM -0600, John Darrow wrote:
>On 13 Nov 2006 22:40:18 -0600, George Georgalis <george@galis.org> wrote:
>>would the invocation 
>>
>>date -R [[[[[cc]yy]mm]dd]hh]mm[.ss] [+format]
>>
>>be a reasonable feature request to date(1)? is there
>>another way to get date [+format] from an arbitrary
>>canonical time?
>
>On unix systems, the "canonical" time format (time_t) is actually
>seconds from the epoch.  The input format shown above is just provided
>by date(1) to make it easier for those silly people who actually want
>to manually fiddle with their clocks.  ;-)

my first draft of the note used "human enterable"
then I looked at the date man to see that the term
canonical was used for that. yes it seems odd that
someone would set their clock with anything but ntp.

>Converting a time_t to an arbitrary string (like the above) is easy;
>just call strftime with the right format, which is exactly what date
>does internally.

well, I'm working on a user space program that
will record arbitrary dates (or even $NOW) into a
database as unix seconds. Subsequently some integer
math may be applied then something to the effect of
hh:mm should be rendered for eg 86000 seconds.

> But going the other way is non-trivial, due to
>having to know when leap years, leap seconds, etc. occurred, which is
>why the system provides a mktime() call which will take a struct tm *
>and convert it into a time_t.  You then just need a parsing routine to
>break your string into a struct tm (substituting current values for
>fields you didn't provide), as done in date.c::setthetime().

I didn't know about that. but in either event I'm just writing a
/bin/sh program, it doesn't seem right to need a complementary
c program for date string manipulation (even if that would be
straight forward for me). It has also been suggested that I use
perl to crunch the strings *sigh*

>It would be trivial (<10 lines) to add a flag to date(1) telling it
>to not set the time, but just parse the string and then print
>according to the format.
>
>The main question is what option letter to use?  -R (like suggested
>above)?  -N (a common "don't actually do it, just show me what would
>happen" option letter)?  Something else?  Is there any prior art for
>this?  Does POSIX or anything else have anything to say?  What color
>should we paint the bike shed? ;-)

after my post, I realized -R could easily be confused for -r (even
by the root user). per the other response, -j sounds good to me.
will it really be that easy? okay to pullup? should I generate a
-j feature request pr?

// George


-- 
George Georgalis, systems architect, administrator <IXOYE><