Datetime field issue with dev

[Soma]

I have a datetime field and using latest dev version, when changing the date and saving, the date field turns out empty after saving.

When dropping in master, it works.

Edit: It seems only to happen when the user has not the default language. If user uses default language the datetime field works. Also maybe it has to do with that the is localized... So If my user is german the date input format is in german localized.

Edit: Yes if I change the input format to not include string dates it works again. So I'm not sure what's about it.

[ryan]

Yes if I change the input format to not include string dates it works again. So I'm not sure what's about it.

Thanks for the report Soma. Can you clarify what you mean by "not include string dates"? Maybe a screenshot of your date field 'details' and 'input' tabs would be good to see. 

[Soma]

It doesn't work if I use "8 März 2012 12:00" type of input. I've set the locale in the translation "de_DE" so the input get's localized depending on the user language.

[ryan]

What is your date input format string?

[Soma]

It doesn't matter, anything that has strings in it for months and days. For example "j F Y" or "l, j F Y" get's cleared when saving.

Following does to work on the other hand "Y-M-j, l" 

[ryan]

If you are actually inputting your dates with translated month names or the like, I don't know of a way to have the system reverse-translate it back to English so that PHP's strtotime() or date_parse_from_format() can understand it. If using multi-language, I think you need to stick with a digit-based date for the input side. Or if you prefer, you can just specify digit-based for your non-English languages by editing the date input format directly from the field settings. If this was working on a previous version of PW, I don't know how it was. The difference in the datetime field between 2.2.9 and 2.2.12 (current dev) is that the jQuery datetpicker language packs are present in 2.2.12. Perhaps they shouldn't be for this reason, though I included them thinking it would be worthwhile for the translation of the widget itself. 

[Soma]

Yep the Datepicker does the translation, and it seems converting it back does fail. In master version 2.2.9 there's no translation happening from the Datepicker, so you're right. Certain formats like "Y-M-j, l" work but get translated back to english when saved which is wierd. I guess the best would be to have the input digit based as you say. I can live with that.

Thanks

[ryan]

What do you think--better to leave out the jQuery UI datepicker translations to avoid this issue, or is it worth the compromise?

[Soma]

No it's nice to have and ... Hmm but it doesnt work at all?! Even with only german as the default.

Damn, all this software is so english orientated. But in this case I think ... Not sure. If we take it out it wont be available in english aswell. Well I tend to think for date inputs it's not that important as long as the output works. But for sure annoying it can't be used.

[ryan]

Damn, all this software is so english orientated.

Well I think in this case, it's just that PHP doesn't have a built-in translation engine for this stuff. Functions like strtotime() do recognize English month names and such, but I think they are really intended to translate the most commonly used date strings to unix timestamps (most of which are digit based). 

If we take it out it wont be available in english aswell.

It would be like it was/is in 2.2.9, as I think English is the default. 

Well I tend to think for date inputs it's not that important as long as the output works.

Maybe I can just put in a note there, along the lines of "Warning: in languages other than English, stick to digit-based date inputs as only English month names are recognized in string-to-time date conversions." … or something like that

[Pete]

I actually had trouble with strtotime the other day because I forgot the date format when just throwing it numbers would be month, day, year, not day, month, year as I had typed.

See, it's confusing for us Brits sometimes too

[ryan]

The Datetime fieldtype no longer relies upon strtotime, as it takes your desired input format and then translates it. So whether 1/2/2013 means January 2 or February 1 to you, ProcessWire will take the lead from your input format, rather than how strtotime would translate it. On the other hand, if you are working directly in PHP with strtotime, then you do have to keep track of how it interprets the different formats. If you go with day/month/year, then you need to use hyphens rather than slashes. If you go with month/day/year then you need to use slashes. 

[MatthewSchenker]

Hi Ryan,

I have been using the Datetime field to do "creative" date presentation.

Just to confirm, below is an example where I have a Datetime field called "created_date," and I call out the individual month, day, and year elements with strtotime.

With the changes you describe, will this this still work:

<div id="news_date_box">
        <span class="month"><?php echo date("M", strtotime("$page->created_date")); ?></span>
        <span class="day"><?php echo date("d", strtotime("$page->created_date")); ?></span>
        <span class="year"><?php echo date("Y", strtotime("$page->created_date")); ?></span>
</div>

Just want to make sure!

Thanks,

Matthew

[ryan]

Matthew, that would still work. But the strtotime calls you have there are unnecessary. If you need to wrap those components in spans, using $page->getUnformatted() might be more efficient than strtotime: 

<div id="news_date_box">
  <span class="month"><?php echo date("M", $page->getUnformatted('created_date')); ?></span>
  <span class="day"><?php echo date("d", $page->getUnformatted('created_date')); ?></span>
  <span class="year"><?php echo date("Y", $page->getUnformatted('created_date')); ?></span>
</div>

or: 

<div id="news_date_box">
  <?php $date = $page->getUnformatted('created_date'); ?> 
  <span class="month"><?=date("M", $date)?></span>
  <span class="day"><?=date("d", $date)?></span>
  <span class="year"><?=date("Y", $date)?></span>
</div>

[lenoir]

Edit: Yes if I change the input format to not include string dates it works again. So I'm not sure what's about it.

Soma, I have the exact same problem as you had, and it took me quite a while to find out that only german users had that problem… 

Did you find a workaround? Could you share it?

Thanks.

[Soma]

There is no solution. I simply don't use named dates for input.

[dazzyweb]

Maybe I can just put in a note there, along the lines of "Warning: in languages other than English, stick to digit-based date inputs as only English month names are recognized in string-to-time date conversions." … or something like that

Just spent the last couple of hours trying to work out why the input dates wouldn't work for non English months until I found this post.

Would be helpful to have a warning note as suggested in Date Input Format for others that come across this issue.

[lenoir]

On 21/01/2013 at 5:03 PM, Soma said:

Yep the Datepicker does the translation, and it seems converting it back does fail. In master version 2.2.9 there's no translation happening from the Datepicker, so you're right. Certain formats like "Y-M-j, l" work but get translated back to english when saved which is wierd. I guess the best would be to have the input digit based as you say. I can live with that.

Thanks

A year and a half later, Soma saves my day. Again. And for the very same issue