Hi Bryan,
This one took a bit long for me - sorry for the delay.
I made two modifications to trace this down. One what I was doing
earlier and the other one what you suggested. The changes ran at the
same Update Issue request:
1. update_form.tpl.hmtl template at line 216, adding the following:
{$smarty.now|date_format} which prints "Sep 22, 115560"
2. Changed the update.php just before the very last line adding the
"echo time(); echo date('r');" line. This one prints " 1155583322Mon, 14
Aug 2006 19:22:02 +0000"
Seems to me the year 115560 comes from the first 6 digit of time()
result (a few ticks ellapsed between the template rendering and the php
execution). The Sep is the result of 33 mod 12 = 9 (month Sep), while
the 22 stands for the day 22 above.
Both old and new environments config details are below at the bottom of
this thread. Both boxes have the same locale settings:
Primary lang:
- English (US)
- Use UTF-8 encoding
- locale setting: en_US
I hope this would help you to identify how to go on. Just let me know if
you need anything else!
Tibor
Tibor Gellert wrote:
> I was on holidays and back now - it is still on my list and hope to
> test the below in 1-2 days. Sorry for the delay!
>
> Kraer, Joseph wrote:
>
>>Was there a resolution to this issue?
>>
>>Joseph "Tito" Kraer
>>
>>-----Original Message-----
>>From: Bryan Alsdorf [mailto:bryan@stripped]
>>Sent: Friday, June 09, 2006 10:49 PM
>>To: tibor.gellert@stripped
>>Cc: Andrey Popovich; Jostein Martinsen; eventum-users@stripped
>>Subject: Re: Expected Resolution Date
>>
>>Tibor,
>>
>>What is printed using the following code?
>>
>>echo time();
>>echo date('r');
>>
>>Also, what locale is this?
>>
>>Best Regards,
>>/bryan
>>
>>Tibor Gellert wrote:
>>
>>
>>>Yeah - its something with current locale, Smarty is sensitive to the
>>>settings on the OS/??? level.
>>>
>>>If I modify the update_form.tpl.hmtl template at line 216, adding the
>>>following:
>>>{$smarty.now|date_format} prints " Jan 6, 114904"
>>>which is not the expected as the OS date reports May 30 2006
>>>
>>>The 114904 figure for the year pushing up the number of elements in
>>>
>>>
>>the
>>
>>
>>>combo-box big time... hence the slow response.
>>>
>>>I am not expert of smarty so please anyone give me directions how to
>>>resolve this locale problem if something easy comes to mind!
>>>
>>>
>>>Andrey Popovich wrote:
>>>
>>>
>>>
>>>>I have same situation. It seems that there are bug with detecting
>>>>current date in update.php. I have years in "Expected resolution
>>>>
>>>>
>>Date"
>>
>>
>>>>till 147560 or something. :) That's why render of this page takes so
>>>>much time (1 combo-box with year value and more that 100.000 values
>>>>
>>>>
>>in
>>
>>
>>>>it).
>>>>
>>>>On Tue, 30 May 2006 13:17:03 +0200
>>>>Jostein Martinsen <jostein.martinsen@stripped> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I might be way out but could this be a glitch in Smarty?
>>>>>One time I saw the same thing, and it was in a almost new install of
>>>>>Eventum. I was unable to reproduce the behaviour.
>>>>>
>>>>>
>>>>>On Tue, 30 May 2006 12:08:08 +0100
>>>>>Tibor Gellert <tibor.gellert@stripped> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I am moving Eventum to a new hardware and hitting the exact same
>>>>>>issue. Environment on old box:
>>>>>>- Eventum 1.6.1
>>>>>>- SuSE 9.3
>>>>>>- MySQL ver 14.7 distrib 4.1.10a
>>>>>>- Apache 2.0.53
>>>>>>
>>>>>>New environment:
>>>>>>- Eventum 1.6.1 (file system level copy)
>>>>>>- SuSE 10
>>>>>>- MySQL ver 14.7 distrib 4.1.13 using readline 5.0
>>>>>>- Apache 2.0.54
>>>>>>
>>>>>>On the old box I use
>>>>>> mysqldump --comments --add-drop-table ... eventum_prod
>>>>>>
>>>>>>
>>>>>>
>>>>>>>ev_prod_db command to dump the data. On the new box I use
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> mysql ... eventum_prod <ev_prod_db
>>>>>>to load the data.
>>>>>>
>>>>>>Any luck fixing this before?
>>>>>>
>>>>>>Thanks for any idea,
>>>>>>Tibor
>>>>>>
>>>>>>Kraer, Joseph wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Bryan,
>>>>>>>
>>>>>>>We've been experiencing the same issues. We discovered it in
> 1.7,
>>>>>>>the week before 1.7.1 was released. We waited for 1.7.1
> because
>>>>>>>
>>>>>>>
>>we
>>
>>
>>>>>>>thought that it was going to be corrected by then. Do you
> have a
>>>>>>>solution for this issue yet?
>>>>>>>
>>>>>>>Thanks,
>>>>>>>
>>>>>>>Joseph "Tito" Kraer Business Systems Analyst Taylor, Bean
> &
>>>>>>>Whitaker Mortgage Corp
>>>>>>>-----Original Message-----
>>>>>>>From: Eric Carlson [mailto:eric@stripped] Sent:
> Wednesday,
>>>>>>>April 05, 2006 6:49 PM
>>>>>>>To: eventum-users@stripped
>>>>>>>Subject: Expected Resolution Date
>>>>>>>
>>>>>>>Hi all,
>>>>>>> I've been receiving calls lately about the slowness of
> Eventum
>>>>>>> when
>>>>>>>attempting to update issues. I recently moved this database
>>>>>>>between two linux machines (Gentoo) in the previous weeks, so
>>>>>>>thought it might have been something to do with that.
>>>>>>>
>>>>>>>As it turns out, it looks like the slowness is related to my
>>>>>>>Expected Resolution Date field. When hitting the update
> button,
>>>>>>>the "Year" field on Expected Resolution Date shows values
> from
>>>>>>>2007 all the way up to 114,432! 2006 is not in this list.
>>>>>>>
>>>>>>>I'm assuming this had to have been due to the export/import of
> the
>>>>>>>database (I used phpAdmin to do this), as this wasn't an
> issue
>>>>>>>previously on the old machine.
>>>>>>>Can someone provide some assistance on how to clean up this
> field?
>>>>>>>
>>>>>>>
>>
>>
>>
>>>>>>>What should the default values be?
>>>>>>>
>>>>>>>Specifics: Eventum 1.7.1, PHP 4.4.0, Mysql 4.1.14, apache
> 2.0.55
>>>>>>>
>>>>>>>Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>--
>>>>>Eventum Users Mailing List
>>>>>For list archives: http://lists.mysql.com/eventum-users
>>>>>To unsubscribe:
>>>>>http://lists.mysql.com/eventum-users?unsub=1
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
