[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: date bug

From: Bob Proulx
Subject: Re: date bug
Date: Sat, 20 Mar 2010 11:48:12 -0600
User-agent: Mutt/1.5.18 (2008-05-17)

Jesse Lloyd wrote:
> echo `date +%X` > /var/www/loger
> 12:29:09 AM
> If I stick that into crontab using crontab -e (*/1 * * * *
> /var/www/test.sh > /dev/null 2>&1)  and cat /var/www/loger after
> crontab has run I get 00:29:09

Sure.  Seems reasonable to me.  What makes you think this is a date bug?
That seems like a huge leap to make considering that date is producing
reasonable output.  If it said that it was Tuesday when you it was
really Saturday then I agree with you.

Doesn't it seem much more likely that it isn't a date bug at all but
is instead simply something happening that you don't understand?
Wouldn't it be much more reasonable to have simply asked why date was
producing different output in the two environments instead of
immediately calling it a date bug?  I am just asking...  Because as
the old saying goes, "You get more flies with honey than you do with

You may want to read the FAQ:


> Why is this?

The output format of date is controlled by your 'locale' setting.
Specifically that is the purpose of the %x and %X output.  It is
locale specific.  Here is what the documentation says.

       %x     locale's date representation (e.g., 12/31/99)

       %X     locale's time representation (e.g., 23:13:48)

Therefore you must have different locales set in your interactive
environment than your system environment.

That is very normal.  It is very common to have a standard locale
environment set for the system and to have a human locale environment
set for interactive use.  The system could be running in the C/POSIX
environment and you could be running in the en_US.UTF-8 environment
for example.  Or just as reasonably you could be running interactively
the de_DE.UTF-8 or fr_FR.UTF-8 locales and so forth.  The large
variation in output from localized commands can be a problem for
system scripts and utilities to deal with appropriately.  Many systems
simply run in the standard C/POSIX locale to get standard output to
avoid the issue.

You can see what locale variables are available by running the locale
command.  Here is the output from my interactive shell environment.

  $ locale

In my case above the ones that aren't quoted are the ones I have
actually set in my environment.  Because normally I set the following
to get me a standard sort ordering while still getting unicode
character support.

  export LANG=en_US.UTF-8
  export LC_COLLATE=C

You would probably have different output depending upon what you have
set in your environment.

You can read more about locales in the man pages.

  $ man 7 locale

You can read more about crontables in the crontab man page.

  $ man 5 crontab

In the C/POSIX locale I get this output:

  $ LC_ALL=C date "+%x %X"
  03/20/10 11:14:26

(You got 10-03-20 telling me that you are using a locale that uses
dashes as date separators.  I am curious as to what locale that would
happen to be?  None of the ones I guessed at matched exactly.)

In the en_US.UTF-8 locale I get this output:

  $ LC_ALL=en_US.UTF-8 date "+%x %X"
  03/20/2010 11:17:56 AM

Personally I think your system being configured for the standard
C/POSIX locale is a good thing.  I would leave it that way.  I
wouldn't rely upon locale specific output because it isn't standard
and is allowed to vary from locale to locale.

Since you want the same format of output in both places then you use
date specifiers that completely describe the format.  Personally for
system use I like the use of "%F %T %z" output.  It sorts nicely and
is unambiguous.

  $ date "+%F %T %z"
  2010-03-20 11:24:05 -0600

But you could easily produce any specific output such as this example:

  $ date "+%m-%d-%Y %H:%M:%S"
  03-20-2010 11:27:31


  $ date "+%d-%b-%Y %I:%M:%S %P"
  20-Mar-2010 11:34:00 am

Hope this helps,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]