Formatting issue

Use backlash (or two), according to PHP date manual:

l, d F \-\|\- H:i

Szy.

I have the same problem

Dates written in Spanish are written like this:

27 de Febrero de 2009 

To achieve this I am using the format

d \d\e F \d\e Y

But the module shows

27 de Febrero de 2009 de de

Checking a bit more to put a call dprint_r () function in date_format_date ()

I noticed that date_format_date () is called twice per field, the second time, this function receives an invalid (or null, I don't know) date. But for some reason this just returning custom chains. Therefore returns:

de de

The configuration of my date field is:

Field type: date
To Date: Never
Number of values: 1
Granularity: Year, Month, Day, Hour, Minute

This bug is still present in version 2.0

I have used google translator to translate this issue. Sorry for my english.

I can fix #3 and just committed something for that. The code cannot handle any character you want to use because it tries to 'know' what part of the formats to strip out for a specific granularity. We did this so that you can use the site format without showing date parts that don't make sense for that type of date so that it can do things like adjust the format to leave out any time characters for a date without time. And then we try to do a 'smart' format of the from and to date when they are different times on the same date, so it looks like 'Tuesday, March 10, 6AM - 8AM' instead of 'Tuesday, March 10, 6AM - Tuesday, March 10, 8AM', and that makes things even more complicated.

I almost ready to throw in the towel and just leave the ugly long combined format in there to avoid these problems.

I don't know if the fix I just committed takes care of everything needed for legitimate international formatting needs to work (I never promised to support any odd character anyone might add to a format string, so I'm not so worried about that). If not, the only thing left is to go back to the long format for the combined date and blindly displaying hours, minutes, and seconds even on dates that don't use them.

Hello Karen:

I have installed your patch and it doesn't fix the problem.

I can fix #3 and just committed something for that

I understand it. And it was not my intention obtain a single solution for me.

The code cannot handle any character you want to use because it tries to 'know' what part of the formats to strip out for a specific granularity

Mmm, ok, but if the character is escaped with a \ it should be interpreted as a character, isn't?

I think that this issue is not a formating problem. I think that date module is render Date 1 'To date' Date 2 even if field date is configured to work with the option 'to date' disabled. But this behaviour is only detected when users uses custom formats with escaped chars.

For this reason maybe the component of this issue is not 'Date API' maybe is a issue to Date CCK field.

Anyway, thanks for help us.
Best regards
Mariano

Hello Karen:

I have reviewed again your code and think that I found the solution.

This patch removes white spaces between chars and now, works fine.

Again, thanks for help us.
Best regards
Mariano

The patch doesn't fix the problem (or doesn't work with latest dev?).

Szy.

Rerolled to 6.2 version.

@Szy: Sorry, but I have tested this patch in my own site: http://cuencodigital.com/articulos here you can see the same example that I use in #3.

@Karens, please let me know if you need a screencast to see what is the problem and how this patch fix it.

With Regards
Mariano

The patch fixes one problem and I'm committing it. The other problem is that you should not escape punctuation in the formats, only escape letters that you want as literal letters in the result.

So l, d F 'y - H:i will show the year and l, d F '\y - H:i will show the literal letter 'y'.

With the changes I'm making now and if you go back and remove escaping from punctuation, things should work correctly.

Problem #3 is still exists in dev version of 7.x
I use format
\l\e l j F Y \à G\hi
and get
le vendredi 28 septembre 2010 à 19h53 leàh

For me with the latest 7.x-1.x-dev package all the formats in #0 and #3 appear correctly. I mark this as closed.