Closed (fixed)
Project:
Date
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
20 Oct 2008 at 20:00 UTC
Updated:
24 Feb 2012 at 09:10 UTC
Jump to comment: Most recent file

In the above field there is a blank option "". Why would this ever be an option?
Since we selected a 12 hour format either am/pm should be selected and it should be required. An empty option here makes no sense.
If we were 24 hour format than this field shoudn't appear at all.
Not sure where to patch this but wanted to point it out, thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | date-323852-9.patch | 1.71 KB | tim.plunkett |
| #6 | date-323852-6.patch | 1.58 KB | tim.plunkett |
| #5 | date-323852-5.patch | 681 bytes | tim.plunkett |
Comments
Comment #1
gregglesSlightly better title.
I agree - if the field is required then there's no reason to have a blank option in the dropdown.
Comment #2
karens commentedThe blank option is there for all fields because the current behavior is that you can leave the 'To field' values blank if you want them to be the same as the 'From field'. That saves a lot of clicking if you have year, month, day, hour, minute, second and am/pm and the only change is the hour, so it's a nice feature.
I guess I can leave the blank option out of the 'From date' value when the field is required, but I'd have to add a couple more checks to the code.
Comment #3
karens commentedI'm not making any more changes to the D5 version other than bugfixes, so I'm going to just mark this by design. If it really bothers you, you can start this up as a D6 issue.
Comment #4
loki6989 commentedHow did you create these time dropdowns programmatically? i'm trying to do this so i can create a entry and exit time fields for a recurring conference module.
Comment #5
tim.plunkettWhen you check off "Collect an End Date" and "Required" for it, the expectation is that it will be required, see #1299030: Missing red star when From Date and To Date are both required.
When all of the date parts are marked required except the am/pm, it's very confusing.
Comment #6
tim.plunkettMore generic fix.
Comment #7
tim.plunkettComment #8
arlinsandbulte commentedHmmm... 'required' end dates in the Date module are a complex & loaded topic...
If the end date is not filled out, Date module ALWAYS stores the end date with the same value as the start date (see #523218: Default value for To date: Blank should stay blank & #874322: To Date & All Day Date Handling).
For select list date field widgets:
As Karen said in #2, if the user filled in the start date, but left some or all of the end date fields empty, the date module would substitute start date values into the end date, if possible. That way, the end user only needs to completely fill out the start date and then only choose the end date elements that are different (for instance only put a new hour in the end date for an event that starts and ends on the same day). This saved a lot of clicks and time for the end user when entering the data.
But, this might be changing now according to #1417872: Date Select does no granularity validation unless year is filled out....
I have not dug into and really tested or thought through all this *stuff* yet...
But, I do think this area of the date module needs a little more thought and planning before we just start pulling a bunch of triggers....
Comment #9
tim.plunkettIn light of the removal of the magic filling of empty end dates, I think this is the right fix.
Comment #10
karens commentedThis patch takes care of every situation but one. If someone has set the default value to be blank but made the field required it will default to the current date instead. The current code will default to blank with that combination. I have had a number of people insist that this kind of option should be available -- they want a blank default date to force the user to select a date, they don't want it to magically default to the current date. With this code change that is no longer possible.
The question is how important is that and is there a way to work around this. Not sure yet what to do with it.
Comment #11
karens commentedActually it doesn't default to the current date, it defaults to the earliest possible date value, which does not match the default value, which is blank, so it also gets stuck in validation if you set this up as a multiple value field and try to add another value. There is also a problem with validation for that situation in the current code, so I need to figure out what to do with that.
Comment #12
karens commentedFound the validation error -- the code that is clearing out un-used end dates was incorrectly interpreting non-optional end dates as though the user had unchecked the end date box.
http://drupalcode.org/project/date.git/commit/863f971
Then I had to add back the check for whether the $date is empty, which was how we were communicating that there is no default value for the date. So in that one case -- a required date with no default value -- we still have to offer empty options in the select lists.
http://drupalcode.org/project/date.git/commit/ffe94fa