Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi,
The function date_combo_validate performs a test at line 510 of date_elements.inc to catch timezone invalid dates, like 2AM on the day that spring DST begins in the US.
The problem I found happens when the granularity of the date field doesn't include HOUR. In this case, the date_convert function will create a date with 00:00:00 info added to it. As an example, if the user inputs a date like "2010/10/17", date_convert will add the hour/minute/second info, creating "2010/10/17 00:00:00" value.
When the timezone invalid date test is performed, it will catch an error in that date if Drupal's timezone is set to America/Sao_Paulo (main brazilian timezone) because in the day DST starts in this timezone, there is no "2010/10/17 00:00:00" as time jumps straight from "2010/10/16 23:59:59" to "2010/10/17 01:00:00". As a consequence the user input to dates like "2010/10/17" with DAY granularity will fail the timezone test and will be wrongly set invalid.
My suggestion is to change the timezone validation tests. It should be performed only in date fields with granularity of at least HOUR. To do this, i propose the attached patch to date_elements.inc
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | date-745074.patch | 2.07 KB | rsevero |
| date_elements.diff | 1.94 KB | rilsonraposo |
Comments
Comment #1
rsevero commentedIt's important to mention that this problem won't affect only brazilian users but users of all timezones that have daylight starting/ending time at 00:00:00 which is not the case of USA but is the case of most countries in the world.
Comment #2
rsevero commentedComment #3
rsevero commentedI have already applied this patch in two different sites and it's working fine.
Comment #4
rsevero commentedI'm returning this issue to "needs review" status as I lacks a standard patch. Anyway all info above stills holds true for this patch.
I can confirm that the troubleshooting steps mentioned on Debugging date and calendar problems page have been tried.
Comment #5
karens commentedI am unable to replicate this problem in the latest code, but it does make sense not to perform this test for dates that don't use time, so I committed something similar to this patch.
For future reference, don't mark your own patches as 'Reviewed & tested by the community', someone else is supposed to test your patch, not you.