(No need to CC me, I'm subscribed) On Tuesday 22 November 2005 09:59, Mathieu Roy wrote: > Monday 21 November, vers 20h, Tobias Toedter écrivit : > > 1. The inverted parameters in format_date() and utils_format_date() > > are a sure way to mess things up sometime. I would strongly suggest > > to uniform the calls; I can do the necessary conversions in the > > code. > > That would sounds good but I'd like such thing to be delayed after 1.3 > release.
Hm, there's currently a bug which would prevent this to work. The function
format_date() accepts a strftime() format string as parameter, the new
utils_format_date() accepts only descriptional text (default, minimal,
short). Thus, you can't just call utils_format_date() from format_date()
the way you do it now.
We can resolve this in two ways: Either revert the utils.php changes in your
branch completely, or fix all calls to format_date in the code, using the
new format parameter (and then changing the parameter order as well).
As I already said, I offer to perform the latter option on your branch. I
could do this tomorrow during the work hours, cause I have a day off. We
could synchronize then, so no merging errors should occur.
If you don't like this option, I propose to create a new branch for the
format_date() issue and to merge this into the mainline after we've
released Savane 1.3.
> > 2. The parameter $default_value is not used anywhere in the code,
> > that's why I didn't implement it in the function. We should probably
> > drop it until we really need it. If the timestamp is null, we can
> > just return "-".
>
> I thought it was used in rare occasion when date information was
> missing (typically, on very old item that were older than the fusion
> of the tracker code: the previous task tracker did not stored many
> date information as the current one does, as result old items got
> missing dates).
> But if a grep shows no more calls of it, sure we can remove it.
My grep didn't show any use cases, I'll remove that parameter then.
> > 3. Do we really need utils_format_date() and format_date()? If the
> > first function name is too long, we can just drop it and use
> > format_date(). I wanted to reduce the code bloat, which is already
> > quite big. So why do we provide an alias for this function, when the
> > alias function is not used anywhere in our code?
>
> I think important to keep a clear policy to name functions, and that
> involve have function name beginning with the file they are in.
>
> But I recognize the need to have, for a few functions, shortcuts,
> aliases, because otherwise the code would be twice longer (and as such
> hard to read).
OK. But I've removed utils_unixtime_to_date(), leaving utils_format_date()
and format_date().
> > 5. I think we should drop $sys_datefmt from the configuration
> > options and hence from the global variables. It's recommended anyway
> > to comment this option out, and the PHP frontend has more than just
> > one format (namely default, short, minimal) to display a date. Thus,
> > it's not enough to control how dates are displayed.
>
> No no, we cannot remove it. It is used on several installation that
> use no localization at all and want to push a unique kind of date
> format.
> If installation want this, we must keep it for them, even if it is a
> not a recommended usage.
> And if it display dates in a stupid fashion, it is their problem, not
> ours, we did our part the best we could.
Hm, if you think that we must support this abuse, I guess I have no
chance ;-)
But seriously, this approach is not consistent. Even though most date
displays can be controlled by $sys_datefmt, there are some displays which
use their own (hard-coded) date format, e.g. the feature boxes and the
display for "Member since June 2004". I still think we should fade out the
support for this custom date format. The change doesn't have to be abrupt,
we can fade out the support over the next few releases.
We seem to agree that $sys_datefmt is an unlucky configuration option and is
not recommended by the Savane development team because it has several
drawbacks. So why keep this forever, instead of providing good alternatives
so that the need for a custom date format is eliminated?
Cheers,
--
Tobias
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former" -- Albert Einstein
pgpI0BZyAbd4m.pgp
Description: PGP signature
