You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the loop at the bottom of GetTimestamp(), the function records a name to delete, and then attempts to parse its value. The result of that parse will be a zero Time value if the parse failed (and if so, the loop continues). But if the loop runs without ever finding a valid timestamp, it will still delete the last field that matched one of the names it's searching.
To be fair, if someone has called a field "Timestamp" and this code can't parse it, there are probably bigger problems. But I noticed this while reviewing the code.
The text was updated successfully, but these errors were encountered:
## Which problem is this PR solving?
- Fixes#238
- Fixes#239
## Short description of the changes
- GetTimestamp violates its documented behavior (fails to delete the timestamp field) if a timestamp matches a certain format. This causes it to do that.
- GetTimestamp looks at a bunch of fields and tries to parse them as a timestamp. If it succeeds, it deletes the field. But there was a bug (see the referenced bug report). This fixes that bug.
In the loop at the bottom of GetTimestamp(), the function records a name to delete, and then attempts to parse its value. The result of that parse will be a zero Time value if the parse failed (and if so, the loop continues). But if the loop runs without ever finding a valid timestamp, it will still delete the last field that matched one of the names it's searching.
To be fair, if someone has called a field "Timestamp" and this code can't parse it, there are probably bigger problems. But I noticed this while reviewing the code.
The text was updated successfully, but these errors were encountered: