Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

custom form with date/time field gives a problem when using as variable in email.


i have made a custom form with a date and time field. When i am using the variable in a email it gives a wrong output its always 01-01-70 01:33 no mather what the input is. In the ticket dashboard the date and time are ok. 
Is there anbody who have solved this or having the same error? 
I am using version 1.10

kind regards


  • How are you putting a variable via email?
  • i have the problem too.

    Variable on email : %{ticket.heurde}

  • I do the same as tocajames
  • What does Heurde mean?
  • I believe that's the variable name used to insert the date field into an email template. Which I've not done, but it might depend on your time format config, or on your timezone, or your form field config..

    Can you share some of that?

    Or it's a bug.
  • the label heurde is a custom label. i use  %{ticket.time} and when you put the label in amail there is data but only the wrong data. In the ticket dashboard the time and date are ok. So i must be a bug. Anyone who can help with that?
  • Yes its the variable name , but if on my forms a select date and time in selector, on report email i have only the same date an time : 01-01-70 01:33

    I try different time format config but not working.

    someone can try the field date and time on V1.10 ?

  • I hope someone can help us with this bug

  • Ok, I got it to add it, and it came out at 01/01/70 10:33AM, which is a touch different to the ticket display: 
    Test Timestamp Field:03/08/17 11:45 AM
    Hilariously, the database (ost_form_entry_values) is storing the value as: 2017-08-03 01:45:00, which must be GMT. 
    So "relative" makes it save as GMT. 

    The change does affect the output though, in that it calculates the timezone offset and subtracts it.. Assumes all timezone changes will incur a negative offset.. hmm. Could be an issue. Because the formatter then converts it back into a timestamp.. WHY NOT JUST STORE A DAMNED TIMESTAMP? 


    Ok, it looks like the VariableReplacer class uses the "asVar" method of an object it is displaying first, and the first function of a FormattedDate object (the output of DatetimeField's asVarType()).. I think. Christ that get's incomprehensible fast! Been playing with it for a bit trying to get it to break more, so I can see where it's getting that value from. Fun times. 

  • Great you are testing it!!!! 
  • anyone has a idea how to fix this?
  • I haven't found a solution yet, I've a few minutes more before work this morning, I'll have a look.
  • ok great! i hope there is! ;-)
  • Found it!

    The correct value is appearing in the asVar method of DatetimeField, however the FormattedDate constructor is called with an erroneous cast (int) $value, simply changing that to strtotime($value) corrects the error. The date was being constructed as if the year was the entire timestamp.. lol.

    To debug/test this:
    modify a form to include a DateTime field, add the form to a ticket, add a value for the field, trigger 
    you need to trigger the sending of an email with the template, so, modify a template to include the variable, %{ticket.variableName}
    Then trigger the template by posting note/message/reply etc, then receive the email it sends.

    I simply pipe it through postcat and base64 decode the file, faster than letting my dev box send the emails, but either way, it's slow. Painfully slow to debug. 

  • hmmm i dont understand this yet. How can i fix this now? 

  • There's a diff in the pull request showing the change to file /include/class.forms.php, basically, replace line 1777 with:

    return new FormattedDate(strtotime($value), 'UTC', false, false);

    But really, all I changed was:
    - remove the (int) cast that was there.
    - add the strtotime function around $value.

  • Thanks!!! i gonna try this! big thanks !!!!!
  • It works!!! but the is also a other bug with the date and time picker. When you select a date then the date is double showed for example 1717-aug-2017. in the ticket details the date is ok. 

    see attachmend for axample. 
  • What is your date format? It's defined in the admin settings? Because it doesn't do that on mine.
    Also, I've updated the pull request to ensure backwards compatibility after a suggestion from someone else. Maybe that's why mine works?
  • I think i have found the problem. The problems are in the default date and time settings from the dutch language pack. So in the english language there is no problem but when changing it to dutch the problem is there. So i have set it by hand now and it works. 
  • The language pack sets the time format? That could be useful I suppose, if it's correct.
    Glad it's sorted mate, hopefully they merge my patch and it's fixed for good.
Sign In or Register to comment.