I’m having trouble submitting date information to HubSpot’s contact API. The system keeps rejecting my timestamp values with an error message saying the UTC date isn’t at midnight.
The error looks like this:
“1505779200 is at 10:16:19.200 UTC, not midnight!”
When I check this timestamp using online converters, it shows the correct midnight value. Here’s my C# method for converting dates:
public static long ConvertToUnixTimestamp(DateTime inputDate)
{
inputDate = DateTime.SpecifyKind(inputDate, DateTimeKind.Utc);
var unixTime = ((DateTimeOffset)inputDate).ToUnixTimeSeconds();
return unixTime;
}
Has anyone encountered this issue before? Any suggestions on how to fix the timestamp format?
This happens when timezone conversions mess with your data before it hits your conversion method. HubSpot’s contact properties need midnight UTC timestamps, and SpecifyKind won’t always zero out the time components properly. That timestamp 1505779200 should be September 19, 2017 at midnight UTC - if HubSpot shows 10:16:19, something’s adding an offset. Try DateTime.UtcNow.Date or inputDate.ToUniversalTime().Date before converting to get a clean midnight value. Also check the actual DateTime in your debugger before conversion to see what time components are there.
check your datetime source first - it’s probably not actually midnight to start with. hubspot’s api is really picky about this. debug by printing the datetime value before you convert it. you’ll likely see hidden time components. i just use inputdate.date.touniversaltime() to force midnight utc before converting to unix timestamp.
Your conversion method looks fine, but the problem’s probably happening earlier. HubSpot’s API is crazy strict about midnight timestamps - even a tiny millisecond offset will get rejected. I hit this same issue last year working with their deals endpoint. Turns out my DateTime objects from Entity Framework were keeping the original database precision. What fixed it was building a fresh DateTime with just the date parts: new DateTime(originalDate.Year, originalDate.Month, originalDate.Day, 0, 0, 0, DateTimeKind.Utc). This gives you clean midnight before conversion. Also check if your system clock or database server has any drift that’s sneaking in fractional seconds.
Had this exact problem about six months back with HubSpot’s properties API. Turns out my DateTime wasn’t actually at midnight like I thought. I added some logging right before the conversion to see what time components were actually there - found out my database query was pulling fractional seconds I didn’t know existed. Try using inputDate.Date instead of the raw inputDate value to force it to midnight. Also check if there’s a timezone offset getting applied somewhere upstream in your data pipeline.
This happens because of precision differences between your local conversion and HubSpot’s validation. I’ve hit this exact issue multiple times migrating legacy contact data. Your conversion logic isn’t the problem - DateTime values often carry microsecond precision even when they look like midnight. Don’t rely on SpecifyKind. Instead, build a completely new DateTime object when you need it: var cleanDate = new DateTime(inputDate.Year, inputDate.Month, inputDate.Day, 0, 0, 0, 0, DateTimeKind.Utc). This kills any hidden precision that’s hanging around. Also test your Unix timestamp against HubSpot’s timestamp validation before the actual API call - catches these mismatches early.