I'm seeing peculiar behaviour on a Date field (not a DateTime field) when we utilize these date fields in a batch.

For instance using the code below:

endDate = Date.newInstance(startDate.Year(), 6, 30);

This sets a value of 6/29/2019 (in this example when I view the record) when we run the batch job. We are in Eastern Daylight timezone (GMT -4:00) in this sandbox - so that is both the default timezone for the company and for my user (who is running the batch and viewing the record).

I'm also seeing this issue when taking the value of a Date field (not a DateTime field) from the Contract and populating it onto a new record being created of the custom object. In that code it is a fairly simple piece and both variables are Date variables.

if (endDate > contractEndDate){
  endDate = contractEndDate;

I'm fairly certain this is a Timezone quirk since I can see the date being set correctly in the debug log when running the batch. It states the field is being set to the following:

11:52:40:299 USER_DEBUG [538]|DEBUG|Insert End Date2020-06-30 00:00:00

My question is - is there a way to set the timezone on a new date field so that it accounts for this and doesn't fall prey to Timezone issues.


  • I am in PST and System.debug(Date.newInstance(date.today().Year(), 6, 30)); returns 2020-06-30. You must be missing something here, because dates are not timezone sensitive. If they were timezone-senstiive, I'd see 2020-06-29 Commented Mar 31, 2020 at 16:33
  • Turns out it was a JSON/Custom Component issue - thanks for your input!
    – cloudcap
    Commented Mar 31, 2020 at 16:54

1 Answer 1


Never mind - it turns out it's a JSON.serialize issue on a Component we use to display the records. When I queried specifically for the date values via Workbench, they came through as they had been set in the batch class. Thanks!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .