Jump to content

Datetime field issue with dev


Soma
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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" 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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>
  • Like 1
Link to comment
Share on other sites

  • 1 year later...

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.

Link to comment
Share on other sites

  • 10 months later...
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.

  • Like 1
Link to comment
Share on other sites

  • 1 year later...
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 :-)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...