Oh god, I feel your pain brother, class.forms.php is a bloody nightmare. I've abandoned all custom forms.I also wouldn't bother running the develop branch, it's develop for a reason mate, not stable. Do let them know the bugs you've found though! :-)The date data does appear to be saved in GMT time, which is sane from a db perspective, specially with users potentially having myriad timezones to display said dates in. Dates are still a bloody nightmare though. https://www.youtube.com/watch?v=-5wpm-gesOYWhen you consider the toString method of the DatetimeField class, it does convert it back based on the configuration: function toString($value) { global $cfg; $config = $this->getConfiguration(); // If GMT is set, convert to local time zone. Otherwise, leave // unchanged (default TZ is UTC) if (!$value) return ''; if ($config) return Format:($value, false, !$config ? 'UTC' : false); else return Format:($value, false, false, !$config ? 'UTC' : false); }Heh, just realised the "global $cfg" is completely unused. The output: Format:/datetime functions do call getTimezone(). One thing that might help, is the EDT thing, it might actually be interpreted as something else, There are currently a few date/time issues in github:https://github.com/osTicket/osTicket/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20timeInteresting: https://github.com/osTicket/osTicket/pull/3623/filesAccording to this: https://github.com/osTicket/osTicket/issues/2769 installing the php_intl module fixed his timezone issue, your status page says you don't have it.. maybe try that? It looks like the date-formatter fallback in format: might not be as accurate as the IntlDateFormatter class, but I really don't want to try and figure it out. Hard!Heh, check out this comment: /* misc date helpers...this will go away once we move to php 5 */Some gremlins in the codebase methinks.