1. Editing node.
2. Saving node
Data From date is: 16 February 2009
Data To date is: 16 February 2009
3. Error:

Data From date is invalid.
Data To date is invalid.

Probably it's related to different language.
When I'm choosing the date from popup calendar I've got: 16 luty 2009 instead of 16 February 2009
And then when I'm replacing it, it's working.

Files: 
CommentFileSizeAuthor
#23 r.jpg13.57 KBWell

Comments

I have a similar problem with just one cck date field (dutch translation).

This only happens when editing the particular node, display runs smoothly.

The funny thing is, it does accept 'Vrij' to be 'Fri'.
But all other short daynames 'Ma','Di','Za',... are considered invalid.

I later discovered that changing the translation to have at least an equal number of letters corrected the situation.
So now I'm using 'Maa','Din',... , but this isn't the proper translation to Dutch.

thx

I got the same error.

It came down to a miss match between the site time zone and the CCK date field ... the latter had UTC as time zone.

But when align the time zones I can save my nodes but #491822: Dates getting decremented when saved by one day, on every submit is popping up.

I would suggest to make this issue critical. Dates are useless now in my To/From usage context :(

Version:6.x-2.0-rc6» 6.x-2.2
Priority:Normal» Critical

Suggestion should be taken seriously. Changed it to critical due to a lot of problems regarding this bug. I am not able to workaround this one.

Version:6.x-2.2» 6.x-2.4
Issue tags:+invalid date from to

Still having these errors when adding content. I tried changing to all sorts of formats and locales.

Each time i get:

The From date is invalid.
The To date is invalid.

No-one else is having this isse??

I am getting this problem - On creating content and importing content with Node_Import

The "invalid date" is 30/04/1933

+1 here!

I'm getting the same issue:

"The From date is invalid.
The To date is invalid."

Screengrab here: http://twitpic.com/m455u

I don't want a separate From date and a To date, just a single date, so I configured the "Default value for To date" as "Same as From date" and I have "To date" set to "Never". I have granularity set to Year, Month and Date, and time zone handling set to "No time zone conversion".

Really surprised and disappointed that this critical bug is still active and unassigned, eight months after being reported!

A bit more detail:

I've checked that it's not to do with the granularity, as I enabled the hours, minutes and seconds too, and set them explicitly, and I still got the same error.

I've also checked that it's not to do with not exposing the To date, as I enabled that, set it explicitly, and still had the same error.

I've figured it out.

I changed my date format to 10.24.2009
So when I edit a node and select a date from the popup calendar, the value have the format month.day.year

Then I go to 'display field' in content types and change the format of the date value to a value I prefer. Which convert 10.24.2009 in for example october 24, 2009

Good luck

It seems like there's a few different things happening here for different people.

It turns out that our problem was actually to do with Quercus, a Java implementation of PHP that we're running Drupal on - see bug report submitted by my colleague: http://bugs.caucho.com/view.php?id=3737

Cheers,

Peter

Doen anyone have an idea about how to solve this problem?
I've a drupal site which default language is italian and when time I edit a node, date fields are shown in english: if I try to save the node as they are I got the "is invalid" error message, and to save the node I have to select the date (setting it to italian, as the popup correctly show dates in italian).
This is a very bad bug, hope there's a solution out there!

S.

Same problem here with german as default language.

I having the same problem. I set the date format for both edit and display to be the exact format. The problem occur when i make the field no editable (only display) on the form. I only use english on my project. There is no problem when i let the field to be editable. but i really need to set the date to be non editable... T-T

Assigned:Unassigned» brankolo

+1 Here!

I've the same problem:

when any user open to edit any node with date, the data field looks in english form, and when saving an error occurred:
Data date is invalid.

It happens when the drupal site is translated to italian language.
Anyway if the user reset the data field it works.

So, until this bug it can't be fixed, i think that i will follow the tip propose by weblinq in his comment
http://drupal.org/node/375193#comment-2186272

Thankyou for your work.

I think that you can follow the tip propose by weblinq in his comment, until the bug will be fixed:
http://drupal.org/node/375193#comment-2186272

I get this problem, and like #6 it is specific to one date (that we've found so far) which is 30/04/2010.

The workaround in #10 does not work for us, unless we are misunderstanding but changing the input format makes no difference.

Thanks.

I fixed this by commenting out the following lines... this of course is not good practice but since I'm not using timezone conversion I hope it doesn't matter and I needed a very quick fix. The lines are 517 - 530 for me in date_elements.inc

      // Test a roundtrip back to the original timezone to catch
      // invalid dates, like 2AM on the day that spring daylight savings
      // time begins in the US.
      // date_timezone_set($from_date, timezone_open($timezone));
      // date_timezone_set($to_date, timezone_open($timezone));
      // if ($test_from != date_format($from_date, 'r')) {
      //  $errors[] = t('The From date is invalid.');
      // }
      // if ($test_to != date_format($to_date, 'r')) {
      //   $errors[] = t('The To date is invalid.');
      // }
      // if (empty($errors)) {
      //   form_set_value($element, $item, $form_state);
      // }

Version:6.x-2.4» 6.x-2.6

Are your problematic date values exactly on those days when a DST change occurred?

This is exactly what's happening here. I have imported thousands of nodes using node import but a few records could no be imported, with a "From/to date is invalid" message. All skipped records have the same date.

I tried to add the nodes manually and also could not input the offending date -- error message was the same.

The date in question is 2009-10-18 and is the exact day when DST began on my timezone.

To add the node I had to add the hour and minute field to the date field granularity, and add the node with a made up time (entering 00:00 for the hour:minute gave me the same "invalid" error message). I then removed the hour/minute granularity afteward and everything is now ok.

(However, it looks like I'll have to do it all again when/if I need to edit that nodes. *sigh*)

My sitewide timezone is set to my local timezone. The date field is set to "no timezone handling". Trying to set the field timezone to match the site timezone was not allowed -- the module complained that I cannot set the TZ handling on a field with only Y/M/D granularity.

BTW, it looks like we have separates issues here. My case has nothing to do with time formats, as the separate date components where being interpreted correctly (thousand on nodes where imported with the right date). Only the actual date value was deemed invalid by the module.

subscribing

Hmmm I just posted a new issue thinking it had not been reported.
See my post: http://drupal.org/node/962526

Yes, this as all to do with entering a date and time on a day that the timezone changed.

My patch skips the playing of the timezone is your date granularity does not include hours.

The file is : date/date/date_elements.inc
Function : date_combo_validate() at line #378
Problem is around lines #500

      // Play with timezones only if granularity is set to minimum of hours
      if (isset($element['value']['#granularity'][3])) {
            $item[$offset_field2] = date_offset_get($to_date);
            date_timezone_set($from_date, timezone_open($timezone_db));
            date_timezone_set($to_date, timezone_open($timezone_db));
            $item[$from_field] = date_format($from_date, date_type_format($field['type']));
            $item[$to_field] = date_format($to_date, date_type_format($field['type']));
            if (isset($form_values[$field_name]['rrule'])) {
              $item['rrule'] = $form_values[$field['field_name']]['rrule'];
            }
            // Test a roundtrip back to the original timezone to catch
            // invalid dates, like 2AM on the day that spring daylight savings
            // time begins in the US.
            date_timezone_set($from_date, timezone_open($timezone));
            date_timezone_set($to_date, timezone_open($timezone));
      }
      if ($test_from != date_format($from_date, 'r')) {
        $errors[] = t('The From date is invalid.');
      }
      if ($test_to != date_format($to_date, 'r')) {
        $errors[] = t('The To date is invalid.');
      }
      if (empty($errors)) {
        form_set_value($element, $item, $form_state);
      }

This patch still validates the dates, but again, if your date includes hours, it will not work.

I have discovered that this error message also applies to Daylight Savings time in America.

I tried creating a Date event for March 13 2am (the official time of the change) and it gave the same errors.

Setting the hour to 1am or 3am works, but setting it to 2am throws the errors.

It may be a different underlining issue for me from those above, but I found this thread trying to figure out how to create an event for Daylight savings on my site's calendar and thought I would add my two pennies.

StatusFileSize
new13.57 KB

I had the same problem with dates (I don't use time and set this field to "No time zone conversion").
I've changed the input format and now it works. Date formats are different, but I don't get error messages anymore.

Status:Active» Postponed (maintainer needs more info)

I can't tell how to reproduce this bug. Apparently it is something that happens only if you are using translation and setting some non-standard input format. I need exact steps to reproduce to be able to do anything with this. The exact steps to reproduce would be something like:

- Create a new Drupal installation.
- Set the language to be XXX.
- Install nothing but Date and CCK.
- Create a field that is configured as follows (paste export of the date field, using Content Copy module)
- Try to create a new date using the following values: xx/xx/xx
- See that there is an error that looks like ....

Status:Postponed (maintainer needs more info)» Closed (won't fix)

No response to my question, so there's nothing I can do.

Component:Date CCK Field» Code

By the way, if you want specific steps to reproduce, please read my previous post :
http://drupal.org/node/962526

Yep, IMHO the steps to reproduce are clearly outlined in the posts above:

  1. Install Drupal
  2. Set user timezone correctly
  3. Enable Date Module
  4. Create date field with daily granularity
  5. Try to input a date when DST changes occur

NB: You can also test using a field having time granularity. You'll see that you also cannot input dates/times near the day begin/end (e.g. 12:20am) on DST change days.

I am witnessing the same error with date 7.x-2.6 and greek translation.
If the format in the form is set to one that contains (greek) letters then I cannot save the node as I get the following error:

The value input for field Ημερομηνία is invalid:
The value 16 Ιαν 2013 08:00 does not match the expected format.

Status:Closed (won't fix)» Needs review

Install and enable 'ClientSide Validation', then in Date field properties enable 'Exclude from clientside validation'. Works for me ;)

31/3/2013 is causing the problem here..

Version 7.22 italian installation.
I had this issue after the upgrading to the last d7 release.

I think it is due to language pack, because it affects only "May" month format

i fix it by changing the format from (let's say) "12 Maggio 2013" to "12/05/2013". In display format on node, you can choose what you want.

Also changing the widget from pop-up calendar to dropdown menu works for me.

Hope this will help somebody