4

So here's what I've found out: EE uses an INT database field to store a UNIX timestamp Because of this, EE can display dates back to about 1901 Switching the database field from INT to BIGINT fixes the problem, but can dramatically increase the size of that database table I discovered the INT vs BIGINT fix through a web search and tested it with success. I ...


3

You could try something like this: {if '{my_date_field format="%g:%i %a"}' == "12:00 am"} {my_date_field format=" %F %j, %Y"} {!-- date without time --} {if:else} {my_date_field format=" %F %j, %Y; %g:%i %a"} {!-- date with time --} {/if}


1

AFAIK there is no automatic way to do this kind of time zone adjustment in EE. EE stores times relative to the server's location timezone, or relative a different timezone if you specify it in the CP. Dynamically modifying the server's default timezone on the fly is not a sensible option, so whatever you do will require you to modify the times shown to the ...


1

You would need to write an Accessory which uses Javascript/jQuery to grab the data in the fields (say when both fields contain something), perform the calculation and insert it into a third field. Start by converting the dates/times into timestamps. This will allow you to subtract one from the other. Then convert the resulting timestamp back into hours. You ...


1

After working with EllisLab support on this issue, it turned out to be a rogue config item in the database for "server_offset" config item. It was set to -1140 for some reason. They were kind enough to decode, unserialize, modify, re-serialize, and re-encode the variable for us and that fixed the problem. Here's the response regarding the resolution from ...


Only top voted, non community-wiki answers of a minimum length are eligible