CiviCRM Community Forums (archive)

We've had CiviMail up and running fine for a long time, but now when we get to the scheduling page the "hour" drop-down selection has gone missing.  I looked in the page code and sure enough, it's just not there.  It skips from the year select element straight to the minute select element (though the colon that would usually separate hour from minute is still there).  I've attached a screen shot.

Our usual contractor for all things Civi is currently in Africa, so I'm a bit out of my element here.  Any thoughts about where I should start?

Thanks!

and ensure that the "Complete Date and Time" in your date input fields is: %b %d %Y, %I : %M %P

most likely the %I is missing in your install

Thanks for the suggestion.  I checked our settings and the "Complete Date and Time" is "%b %d %Y, %I : %M %P", so it looks like that is good.

I also checked the event log and apache error log and I don't see anything unusual.

Does it also happen on any other such screens (i.e., ones with the full selection of month/day/year hour:minute drop-downs)?

Do you mean on pages such as this one from adding a new event to a contact?

Yes, exactly.

If so, then no.  All drop-downs are present, including the hour.  The only place I've seen the missing hour entry is on the mail scheduling page.

This is very strange, then. (Note that the sets of drop-downs in your two screenshots differ – one is for a 12-hour AM/PM time, the other is for 24-hour time, so they don’t really compare…)

can we get ssh access to your machine? if so, jump on IRC and ping one of us.

Note that this week the civicrm team is on "spring/ski break". coverage will be spotty

lobo

I'm seeing this same problem.  It's being caused by a difference in between Date Input Fields -> Complete Date and Time, and the value for 'mailing' under Advanced Date Input Settings (ADIP).  The setting in our database, apparently the default is:

%b %d %Y, %I : %M %P

Yet the default value for 'mailing' under ADIP is "Y M d H i".  One thing that I find confusing is that the Complete Date and Time is using Posix date notation, whereas the "mailing" date spec is using a PHP-style date notation.  For the sake of consistency, it seems like they should use the same notation.  But because they don't, the function posixToPhp() on line 487 of CRM/Utils/Date.php is necessary to translate between the two.

The problem is that the strtr() function isn't going to find a replacement for %I, since H is 24 hour notation and %I is for 12 hour notation.  So what you get when those two formats don't match is missing elements.  A solution is to make sure that the date spec for 'mailing'  matches the main Complete Date and Time spec, but you'll have to do the translation from Posix to PHP in your head.

I have to admit that I'm confused about why the posixToPhp() function exists and why it's used here.  If someone is going to specify their own date spec in PHP format, then why have it try to associate values from the overall Complete Data and Time spec?  Why not just have the 'mailing' date spec be the mailing date spec and leave it at that?  The way it is now causes for a confusing interplay between the two.

This almost seems like a bug to me, but I figured I'd wait to see how people respond here before I filed a bug.  Perhaps there is something reason for all this that I just don't know.  In the meantime, if you want the hour field to show up, then either change the %I of Complete Date and Time to be %H, which will match the H in the 'mailing' spec, or else change the 'mailing' date spec to have an h instead of an H.

Aloha,

Nathan

But why the funny interplay between those two values?  Why not just use one or the other?  What's the need for trying to merge them somehow with the posixToPhp() function?  Seems to me that if the application sees a valid setting for 'mailing' that it should just use that one and forget about the other global config.  It seems like a very error prone operation and it's not clear to me why it's even done.  I ask these questions legitimately, not critically or with sarcasm.  Most likely there is some good reason of which I'm simply unaware.

Also, for what it's worth, there's a big side of me that says: CiviCRM is a PHP application, so the PHP API should be used as is rather than trying to jump through hoops to give a veneer of the Posix date specs, when under the hood it's PHP.  Especially considering that there is presently a confusing mix of the two.  I think it would be less confusing to just fix on the one your language supports, and that it's not too much of a  leap for people to simply reference the date() function's implementation on php.net ... or just link to that spec from applicable pages.

Nathan

I agree that exposing both PHP- and POSIX-style date notations in the UI is a bug – thanks for pointing it out!

I filed CRM-4893 so we can fix it in the next CiviCRM version.