A recent issue with importing a repository (discussed elsewhere) boiled down to Phabricator failing to import artificial commits with 64-bit timestamps, corresponding to an authorship date in 40,000 AD. The script generating these commits was likely writing milliseconds-since-epoch instead of seconds-since-epoch into the date fields.
These timestamps do not fit into a Phabricator "epoch" column (currently uint32) and MySQL fails when inserting them with a "value out of range" error:
(AphrontQueryException) #1264: Out of range value for column 'epoch' at row 1
Specifically, the %ct for these commits was approximately 1000x larger than the current timestamp:
$ git log --format='%H %ct' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1470000000000 # Current Epoch Timestamp: 1470000000
git itself parses and display these commits, but with a date in 40,000 AD, interpreting the timestamp as seconds-since-epoch.
One way we could probably fix this is by changing epoch to uint64 internally. This is a small change in a technical sense, but might have far-reaching implications, and not a change we otherwise need to make until approximately 90 years from now (circa 2106 AD).
These timestamps are also incorrect (the commits were not committed in 40,000 AD in any sense, even a mythological or narrative sense, and the values are purely mistaken) and appear to be impossible to create with user-level git commands. In particular, using --date to set a commit date does not appear to allow you to choose a date beyond 2099 AD.
We can alternatively clamp these dates into the uint32 range, e.g. by replacing them with the current timestamp. This is similar to the behavior of git commit --date, which replaces dates beyond 2100 AD with the current date.
At least for now, I am inclined to clamp the dates. It would be relatively easy to unclamp them later if/when we do move to 64-bit epoch timestamps.