The use case would be for when sequencers finish uploading to arvados, we can set the timer to delete that data after some designated time period.

Trash times could be specified in 2 ways:1. Absolute datetime: Could be accepted from a param like --trash_at "YYYY-MM-DD HH:MM"2. Relative times: Could be accepted from a param like --trash_after XX (where XX is number of days)

Both parameters would be mutually exclusive.

The accepted format for absolute datetimes would be the one described at https://en.wikipedia.org/wiki/ISO_8601The accepted relative time parameter unit will be number of days (to be converted to amount of seconds) and it should take into account possible timezone changes.

The relative trash time should take note of the upload finish process datetime. When uploading using the "rsync mode", it should update the trash_at value when checkpointing.

Not sure why you're rounding off to hours if the timezone struct has the offset in seconds? Also why calculate a negative offset and then subtract it when the source value is meant to be added?

+ logger.error("--trash-at argument should be set in the future")
+ sys.exit(1)
+ if args.trash_after is not None:
+ if args.trash_after < 1:
+ logger.error("--trash-after argument should be >= 1")

"should" → "must" since it is being enforced.

What happens if the user gives YYYY-MM-DD with no time? My guess is that you probably get 00:00 (midnight) at the start of the day as the expire date, but we should confirm. We should also consider if it would be more user friendly to make the expire date 23:59 at the end of the day. Does it accept YYYY-MM or YYYY? ¿En Español se escribe "AAAA-MM-DD"?

So '2019-06-12 4:51:00' fails but '2019-06-12 04:51:00' works, it looks like the parser is very particular about field widths. (Also noticed that it is documented to have a 'T' in between the date and time but it also accepts a space).

I'll leave this one up to you if you want to do anything about it, otherwise LGTM.