How to Bulk Edit Date Properties in HubSpot

Date properties in HubSpot seem simple on the surface. You pick a date from a calendar widget, it gets saved, and it shows up in reports and filters. But under the hood, HubSpot's date handling has quirks that trip up almost everyone who tries to work with dates at scale: midnight UTC normalization, timezone-dependent display behavior, format inconsistencies between the UI and API, and silent data loss during CSV imports when the format does not match what HubSpot expects.

If you need to bulk-edit date properties -- correcting close dates on deals, setting renewal dates on custom objects, updating event dates across contacts -- this guide will help you avoid the common traps.

How HubSpot stores dates

HubSpot stores dates as Unix timestamps in milliseconds at midnight UTC. When you set a date of March 15, 2026 in the HubSpot UI, what is actually stored is:

1773792000000

That is the Unix timestamp for March 15, 2026, 00:00:00 UTC, in milliseconds.

This has two important implications:

Date-only properties vs. datetime properties

HubSpot has two date-related property types:

• Date picker (date only) -- stores a date without a time component. Internally, it is midnight UTC on the specified date.
• Date and time (datetime) -- stores both a date and a time.

For date-only properties, HubSpot always normalizes to midnight UTC. This means that when users in different timezones view the same date property, they should see the same date -- but this does not always work perfectly. A date stored as midnight UTC can display as the previous day for users in western hemisphere timezones in some contexts.

The timezone display problem

If you set a date to March 15, 2026, HubSpot stores it as midnight UTC on March 15. When a user in US Pacific time (UTC-7) views this in certain contexts, the timestamp resolves to March 14, 2026 at 5:00 PM Pacific. Most of the time, HubSpot's UI is smart enough to display the date correctly as March 15 regardless of the user's timezone. But in some edge cases -- especially in exports and API responses -- you may see off-by-one-day errors.

This is not a bug you can fix by editing the data differently. It is a display issue in how timestamps near midnight are interpreted across timezones. Awareness of it helps you understand why dates sometimes look "off" when you export or process them programmatically.

Common reasons for bulk date edits

Correcting close dates on deals

Sales reps are notoriously bad at updating deal close dates. When a deal's expected close date passes without closing, the date should be updated to a new expected date or the deal should be marked as lost. In practice, hundreds of deals end up with close dates in the past while still sitting in open pipeline stages.

Setting renewal or contract dates

For subscription businesses, you may need to set contract start dates, renewal dates, or expiration dates across a batch of customer records when terms change or when migrating from another system.

Correcting import errors

Date format mismatches during CSV import are one of the most common import problems. If dates were imported in the wrong format, they may have been silently mangled -- "March 1" interpreted as "January 3" when the format was DD/MM/YYYY instead of MM/DD/YYYY.

Standardizing date data from mergers or migrations

When consolidating data from multiple sources, date properties often need normalization. One system might store dates as "2026-03-15", another as "03/15/2026", and a third as "15 Mar 2026."

Method 1: HubSpot native bulk edit

HubSpot's bulk edit supports date picker properties. Select records from the index page (including a "Select all" option for the filtered view), click Edit, choose the date property, and pick a date from the calendar.

When this works:

• You need to set the exact same date on a batch of records. For example, setting a "Renewal Date" of December 31, 2026 on 50 customer records.

When this does not work:

• Each record needs a different date.
• You need to shift dates (add 30 days, move to the first of the month, etc.).
• You need to correct dates that were imported in the wrong format.
• You need to set different dates per record at scale.

Method 2: CSV import

CSV import is the most common method for bulk date updates, and it is also where most problems occur.

Date formats HubSpot accepts

HubSpot's import tool accepts these date formats:

• YYYY-MM-DD (ISO 8601) -- recommended
• MM/DD/YYYY (US format)
• DD/MM/YYYY (European format) -- ambiguous and risky
• Unix timestamp in milliseconds

During import, HubSpot attempts to auto-detect the date format. This auto-detection is the source of most problems. If your dates are 01/03/2026, HubSpot cannot tell whether you mean January 3 or March 1 without additional context. It guesses based on the values in the column, and it does not always guess correctly.

Best practices for CSV date imports

1. Always use ISO 8601 format (YYYY-MM-DD). This format is unambiguous: 2026-03-15 is always March 15, 2026. HubSpot will never misinterpret it.

2. Convert dates in your spreadsheet before exporting to CSV. In Google Sheets, use =TEXT(A2, "YYYY-MM-DD") to format a date cell as ISO 8601. In Excel, use a custom format or =TEXT(A2, "YYYY-MM-DD").

3. Watch out for Excel's date formatting. Excel aggressively converts text that looks like a date into its internal date serial number. When you save as CSV, it writes the date in your locale's format, which may not be what HubSpot expects. To prevent this:

   • Format the date column as "Text" before entering or pasting data.
   • Or use Google Sheets, which is less aggressive about date conversion.

4. Verify with a small test import. Before importing 10,000 records with updated dates, import a test batch of 5 records and verify the dates are correct in HubSpot.

Handling datetime properties in CSV

For datetime properties (as opposed to date-only), HubSpot accepts:

• YYYY-MM-DD HH:MM (24-hour format)
• YYYY-MM-DD HH:MM AM/PM (12-hour format)
• Unix timestamp in milliseconds

Timezone handling during import: HubSpot interprets times as being in the portal's timezone setting. If your portal is set to US Eastern and you import "2026-03-15 09:00", it will be stored as 2026-03-15 14:00 UTC (during daylight saving time) or 2026-03-15 09:00 EST.

Method 3: Workflows

Workflows can set date properties to specific values or use relative logic.

Static date setting. A workflow action can set a date property to a specific date. This works the same as bulk edit -- one date applied to all enrolled records.

Relative date operations. HubSpot workflows cannot natively perform date arithmetic (add 30 days, subtract a week). However, with HubSpot Data Hub (formerly Operations Hub) Professional's custom-coded actions, you can write JavaScript to calculate new dates based on existing property values.

Example custom-coded action to add 365 days to a renewal date:

const hubspot = require('@hubspot/api-client');

exports.main = async (event) => {
  const currentRenewal = event.inputFields['renewal_date'];
  if (!currentRenewal) return;

  const currentDate = new Date(Number(currentRenewal));
  currentDate.setFullYear(currentDate.getFullYear() + 1);

  return {
    outputFields: {
      new_renewal_date: currentDate.getTime().toString()
    }
  };
};

This is powerful but requires Data Hub Professional ($800/month as of early 2026) and JavaScript knowledge.

Method 4: HubSpot API

The API gives you full control over date property values. Dates in the API are represented as Unix timestamps in milliseconds (for both date-only and datetime properties).

Reading a date property:

GET /crm/v3/objects/deals/{dealId}?properties=closedate

Returns something like:

{
  "properties": {
    "closedate": "1773792000000"
  }
}

Setting a date property:

PATCH /crm/v3/objects/deals/{dealId}
{
  "properties": {
    "closedate": "1773792000000"
  }
}

You can also use ISO 8601 date strings in API write operations:

{
  "properties": {
    "closedate": "2026-03-15"
  }
}

HubSpot will convert the ISO date to a midnight UTC timestamp internally.

Common API date operations:

To shift all close dates forward by 30 days:

1. Fetch deals with the closedate property
2. For each deal, parse the timestamp, add 30 days (30 * 24 * 60 * 60 * 1000 milliseconds), and update
3. Handle rate limiting and pagination

To set close dates to the end of the current quarter:

1. Calculate the timestamp for the last day of the quarter
2. Update all matching deals with that timestamp

Method 5: Search-and-replace for date-adjacent text

Date properties stored as Unix timestamps are not directly suitable for text-based search-and-replace. You cannot search for "March 15" in a timestamp field because the stored value is a number.

However, there are date-related scenarios where search-and-replace is useful:

Date references in text fields. If dates appear in free-text properties (deal descriptions, notes, custom text fields), they can be found and updated with text search. For example, if deal descriptions reference "Contract start: 1/1/2025" and you need to update them to "Contract start: 1/1/2026," a search-and-replace tool handles this cleanly.

Date format strings. If a previous import stored dates as text strings instead of proper date values (e.g., a text property containing "03-15-2026" instead of a date picker property), you can use search-and-replace to standardize the format before migrating the data to a proper date property.

Year references in content. Blog posts and CMS content with hardcoded year references ("Our 2025 product lineup") can be updated with a simple find-and-replace.

Common date editing mistakes

Off-by-one errors from timezone confusion

The most insidious date bug. You set a date to March 15 via the API using midnight UTC. A user in California sees March 14 in an export. The data is technically correct -- it is March 15 at midnight UTC -- but the display confuses people.

Prevention: For date-only properties, set the time to noon UTC (12:00:00) instead of midnight. This ensures the date displays correctly in every timezone from UTC-12 to UTC+12. In milliseconds, add 43200000 (12 hours) to the midnight timestamp.

Excel mangling dates during export/import

You export from HubSpot, open the CSV in Excel, and Excel converts your timestamps to its internal date format. You make your edits and save. When you re-import, the dates are wrong because Excel changed the format.

Prevention: Open the CSV in a text editor to verify the date format before importing. Use Google Sheets instead of Excel for date-heavy work, or set the column format to "Text" before opening the file.

Importing dates in the wrong locale format

01/02/2026 is January 2 in the US and February 1 in Europe. HubSpot guesses, and it does not always guess right.

Prevention: Always use YYYY-MM-DD format. It is unambiguous everywhere.

Forgetting to handle blank dates

If your bulk update includes records that should not have a date value (or should have the date cleared), make sure your import file or script handles empty values correctly. In CSV imports, an empty cell for a date property will either leave the existing value unchanged or clear it, depending on HubSpot's import settings. In the API, sending "" or null clears the property.

Validation after bulk date updates

After any bulk date edit, verify the results:

1. Spot-check in the UI. Open 5-10 records and confirm the date displays correctly in the property panel.
2. Check in a filtered view. Create a view filtered by the date property you updated (e.g., "Close date is after March 1, 2026") and confirm the expected records appear.
3. Export and compare. Export the updated records and compare the date values to your source data. Look specifically for off-by-one errors and format mismatches.
4. Check reports. If the date property feeds into reports or dashboards, verify that the reports reflect the updated data correctly.

---

Date properties are one of those areas where getting the details right matters enormously. A close date that is off by one day might not seem critical until it shifts a deal into the wrong quarter in your revenue report. Whether you are using CSV imports, API scripts, or a combination of tools, always validate your date changes thoroughly and prefer the unambiguous ISO 8601 format whenever possible.