Subject: Re: date feature request
To: None <firstname.lastname@example.org>
From: George Georgalis <email@example.com>
Date: 11/14/2006 09:54:47
On Tue, Nov 14, 2006 at 12:12:23AM -0600, John Darrow wrote:
>On 13 Nov 2006 22:40:18 -0600, George Georgalis <firstname.lastname@example.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
>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
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 Georgalis, systems architect, administrator <IXOYE><