Development

#2896 ([PATCH] Hours & Minutes not parsed by sfI18N::getTimestampForCulture())

You must first sign up to be able to contribute.

Ticket #2896 (reopened defect)

Opened 5 months ago

Last modified 5 days ago

[PATCH] Hours & Minutes not parsed by sfI18N::getTimestampForCulture()

Reported by: kokozedman Assigned to: fabien
Priority: major Milestone: 1.0.18
Component: i18n Version: 1.0.18
Keywords: Cc:
Qualification: Ready for core team

Description

When parsing timestamps from time-enabled date fields, the Hours and Minutes are ignored, and always gets set to 0, that means, I get 0:00.

Making it happen

Inside a template, have an input_date_tag() with the attribute withtime set to TRUE:

<?php echo input_date_tag('date_with_time', time(), array('rich' => true, 'withtime' => true)); ?>

Have it submitted into a form, and get the time-stamp with the sfI18N in the Action:

$this->getContext()->getI18N()->getTimestampForCulture($this->getRequestParameter('date_with_time'), 'en_US');

It will ignore any time that you specify (Hour, Minute), and will only take into account the dates (Year, Month, day).

Source of the Problem

Line 160 of file i18n/sfI18N.class.php, which is the return expression of the sfI18N::getTimestampForCulture() method, have this buggy line:

return mktime(0, 0, 0, $m, $d, $y);

It takes the Month ($m), Day ($d) and Year ($y) from sfI18N::getDateForCulture(), but does not take the further steps to parse the Hour and the Minute. It is clear that these have been hard-coded to 0.

Consideration

I have found this bug since 1.0.8 and even on the stable 1.0.11, and probably on the SVN; but I forgot to report. This really needs to be fixed on the next stable release, and must be fixed before 1.1.0 is out.

Attachments

bug2896-bigmadwolf1.diff (1.8 kB) - added by BigMadWolf on 05/12/08 18:26:19.
Patch proposal
bug2896-kokozedman.diff (1.9 kB) - added by kokozedman on 06/15/08 14:13:38.
Another patch proposal based on the one provided by BigMadWolf?

Change History

05/12/08 14:59:46 changed by BigMadWolf

  • version changed from 1.0.11 to 1.0.15.

05/12/08 18:26:19 changed by BigMadWolf

  • attachment bug2896-bigmadwolf1.diff added.

Patch proposal

05/12/08 18:39:04 changed by BigMadWolf

We still get the same issue in version 1.0.15.

Please could you have a look at my attached patch? I added a method sfI18N::getTimeForCulture() which does the same thing as sfI18N::getDateForCulture() but for time values (format HH:mm). Then this method is called in sfI18N::getTimestampForCulture() in order to handle hours and minutes from time-enabled date fields.

This works well, but you might think it's more a hack rather than a proper patch.

05/12/08 19:02:24 changed by BigMadWolf

  • qualification changed from Unreviewed to Ready for core team.
  • summary changed from Hours & Minutes not parsed by sfI18N::getTimestampForCulture() to [PATCH] Hours & Minutes not parsed by sfI18N::getTimestampForCulture().

06/15/08 14:13:38 changed by kokozedman

  • attachment bug2896-kokozedman.diff added.

Another patch proposal based on the one provided by BigMadWolf?

06/15/08 14:22:11 changed by kokozedman

  • version changed from 1.0.15 to 1.0.16.

BigMadWolf?,

I have applied and tested the patch that you made. It's not working for my case. I have culture en_US most of the time, and sometimes fr_FR.

I have not tested with culture fr_FR though, but I just noticed that it has created a new bug, and it does not even parse correctly for en_US.

I've attached another patch based on your original patch, that fixes the bug I encountered in your patch. For me, this patch works, but I think it will need a slight review.

06/23/08 04:29:38 changed by dwhittle

  • milestone set to 1.1.0 FINAL.

This is fixed in my branch in r9760 and should be in 1.1.

06/25/08 13:11:50 changed by FabianLange

  • status changed from new to closed.
  • resolution set to fixed.

(In [9853]) 1.1: fixed I18N timestamp handling, using Dustins r9760 + added tests. closes #2896, #2570.

06/29/08 23:39:16 changed by FabianLange

  • milestone changed from 1.1.0 FINAL to 1.1.0.

07/15/08 13:10:05 changed by FabienMarchewka

  • status changed from closed to reopened.
  • resolution deleted.

This bug still exist in 1.0 branch (branch I use : long term support by sensio).

07/15/08 13:18:21 changed by FabienMarchewka

  • version changed from 1.0.16 to 1.0.18.

07/15/08 13:18:44 changed by FabienMarchewka

  • milestone changed from 1.1.0 to 1.0.18.