I'm seeing two separate but related problems with inputting date values using the Text field widget:
1) When the field is set up to allow minute granularity, the values that the user inputs get rounded to the nearest 15 minutes (the same is true for seconds granularity, though they get rounded separately). Why? Isn't the point of using a text field input widget so that you can store date values with whatever time you want?
2) When the user inputs a value that would get rounded upwards to the next month (e.g. 2012-11-30 23:59), the rounding code is bugged, giving bizarre results. Here's what I've seen so far:
2012-11-30 23:59 rounds to 2012-12-31 00:00
2012-12-31 23:59 rounds to 2013-02-01 00:00
2013-01-31 23:59 rounds to 2013-03-04 00:00
2013-02-28 23:59 rounds to 2013-03-29 00:00
2013-03-31 23:59 rounds to 2013-05-02 00:00
I tested all this on a clean Drupal 7.12 install with only Date 7.x-2.x-dev installed, and only the 'date' module enabled.
The most obvious solution is to disable rounding. Why is it even happening in the first place? It seems like it may have accidentally been enabled for text field input by whatever code causes the select list to only offer 15-min and 15-sec intervals.
I think the culprit is likely the form code, since this rounding occurs even when I do a node preview, and by that time the original input field has changed to the rounded value as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | Dates-input-using-Text-fields-are-improperly-rounded-1549834-15.patch | 4.31 KB | samuel.sirois |
Comments
Comment #1
ferahl commentedEdit: nerver mind I see this is fixed in 2.6
Comment #2
coredumperror commentedI just checked this, and no, it's not fixed in 2.6. I'm using 2.6, and I tried inputting a date with time 16:01, and it rounded to 16:00. I also tried inputting a date of 2013-02-28 23:59, and it rounded to 2013-03-29 00:00.
This is still badly broken, and seriously needs to be fixed.
Comment #3
Scott Robertson commentedHave you ran the update script? I was still having this problem in 2.6, until I realized that I hadn't ran any database updates. Doing so fixed the problems I had with the minutes being rounded on date text fields.
Comment #4
coredumperror commentedOK, I think my original problem comes down to my ignorance (or perhaps the original lack of) the "Time increments" option in the hidden Date field settings. Setting it to "1 minute" instead of the default "10 minutes" seems to have finally removed the unwanted rounding.
However, when the setting is anything other than "1 minute", the rounding that it does on month boundaries is still badly bugged. As mentioned before, "2012-02-28 23:59" gets rounded to "2012-03-29 00:00". This is, obviously, a serious problem for anyone who want to create a date field which goes all the way until the end of the day of the last day of a month (not an uncommon thing for multi-day events).
Comment #5
zabelc commentedI just did a completely fresh install with 7.x-2.6, and I'm having this issue; but I don't see any "Time Increments" option when I create the field.
Can someone explain where exactly that option appears?
Comment #6
zabelc commentedI finally found the "Time Increment" option: it only appears once you enable the "Date Pop-up" sub-module, and then only if you set your widget type to "Pop-up Calendar".
The "Time Increment" option is NOT present for the simple default "Text field" widget.
Comment #7
coredumperror commentedYes, you're right. I discovered this problem as well, when I ported my original findings to other date fields on my site. Sorry for not mentioning that.
This bug makes the text widget for dates both almost useless and also buggy. Please fix this!
Comment #7.0
coredumperror commentedadded more detail
Comment #8
btown commentedThis was a problem for me too. I'm using Date-7.x-2.7 and I added a date field that uses the text field widget. The time kept on being rounded to the nearest 15 minute increment.
I was able to correct this by changing the widget to the popup option. I then went into "more settings and values" for the field and changed the increment to 1 minute. After saving these settings, I was able to change the widget back to the text field option (the 1 minute increment setting persisted).
Buggy indeed...
Comment #9
2phaThe above workaround posted by btown worked for me. Thanks.
Comment #10
TangMonk commentedsame issue, why Date not provide a 'Disable Rounding' option?
Comment #11
TangMonk commentedis possible to implement hook_form_alter to trick this issue?
Comment #12
aaronelborg commentedI'm not totally sure why an increment of 15 minutes would be desired by default? To me, it would make more sense to give a '0 increment' value by default and then let the user change that. By changing that value, it makes this issue somewhat easier to manage. My cursory tests checked out ok but, obviously, this should be reviewed and tested before putting it into a production environment.
Comment #13
ronino commentedIt might not be a good idea to just change the default increment value as suggested by AaronElBorg in #12.
The workaround of #8 worked for me, too.
#1355256: date field minutes and seconds rounding after update/save is related and this seems to be a duplicate.
Comment #14
aaronelborg commented@Ronino
For the record, that wasn't the only change I suggested. There's a legitmate bug that is fixed as well.
It just doesn't seem very user-friendly (to me, anyway) to simply assume that a 15 minute rounding is desired by everyone. I just tied the 2 "fixes" together. That's all.
Just curious as to why you think so. I'm not trying to be snarky. Just interested in why. Thanks.
Comment #15
samuel.sirois commentedThis is old, but I still can reproduce this bug with 7.x-2.x as of now.
If I may, I believe the patch provided in comment #12 might solve the issue, but I do not think it highlights the default behaviour.
As @zabelc says in #6 :
.
With that in mind, I think a solution could be to apply the "Time Increment" factor when, and only when, the "Time Increment" option is available on the selected widget.
Here is a patch, representing the idea expressed by my comment.
Comment #16
damienmckennaThanks for the patch, we'll try to review it soon.
BTW when you upload a patch it helps to set the status to "needs review", that triggers the testbots and lets others know that there's something review.