For example, if you run ReplaceTimesByFunc on the string "1000 widgets" the current version of the date parser thinks 1000 is a year, so ReplaceTimesByFunc would replace that number with whatever is returned by the passed-in func(time.Time) string.
There are at least three possible ways to deal with this:
Don't allow bare years to be treated as dates. Require either a month like "September 1000" or an epoch like "1000AD".
Don't bother with years before 2000 since that will probably be enough for most use cases.
Let the caller figure it out by passing in the raw string that was parsed to get the time.Time.
Option 2 would mean ints that happen to match 2\d{3} would always get treated as years. That seems problematic.
Option 3 would have been nice to have included in the original signature. However, it's not backwards compatible with the existing release, so it would require a major version bump. Also, it would not necessarily provide enough context for the caller to determine whether a year really is meant.
Option 1 seems like the best of the three since it is more likely to produce the intended result.
For example, if you run
ReplaceTimesByFuncon the string "1000 widgets" the current version of the date parser thinks 1000 is a year, so ReplaceTimesByFunc would replace that number with whatever is returned by the passed-infunc(time.Time) string.There are at least three possible ways to deal with this:
Option 2 would mean ints that happen to match
2\d{3}would always get treated as years. That seems problematic.Option 3 would have been nice to have included in the original signature. However, it's not backwards compatible with the existing release, so it would require a major version bump. Also, it would not necessarily provide enough context for the caller to determine whether a year really is meant.
Option 1 seems like the best of the three since it is more likely to produce the intended result.