[ZendTo] Expire Time Incorrect

[Der PCFreak]

Hi Jules,

I am currently facing the same problem with a Dropoff made from an 
external user via the public site.


It shows exactly the same days as Michael Imlay wrote (10919 days + some 
hours).

I am running

```
Installed Packages
Name        : zendto
Arch        : noarch
Version     : 6.01
Release     : 2
Size        : 9.5 M
Repo        : installed
 From repo   : ZendTo
Summary     : Web-based File Transfer and Storage System
```

on `CentOS Linux release 7.8.2003 (Core)`.


In the admin interface (Global Drop-off List) the `Created` date is 
`2020-07-08 10:31:19`. This is also stated in the corresponding emails.

We have a retention time of 7 days. The DropOff was sent to 2 recipients 
within our companies (if that matters somehow?).
The size was 3.9 GB and SHa-256 Checksum was `Not calculated`.

Btw. in the `Drop-Off Summary` it correctly shows `This drop-off will 
expire in 23 hours and 31 minutes.` which is correct.

Any ideas?

Kind regards

Peter

On 10/06/2020 18:11, Jules via ZendTo wrote:
> Michael,
>
> What version are you running?
> And what are you running it on?
>
> Jules.
>
> On 10/06/2020 16:55, Michael Imlay via ZendTo wrote:
>>
>> Hey,
>>
>> I have my ZendTo configured to send out a notification started 3 days 
>> prior to removing the files. On the site it shows correct, but the 
>> user who receives the e-mails gets something like this:
>>
>> *This is a reminder about a drop-off sent to you, that no one has 
>> picked up.**
>> *The drop-off will expire in 10911 days and 16 hours after which it 
>> will be automatically deleted.**
>>
>> **
>>
>> *This is a reminder about a drop-off sent to you, that no one has 
>> picked up.**
>> *The drop-off will expire in 10912 days and 16 hours after which it 
>> will be automatically deleted.**
>>
>> **
>>
>> *This is a reminder about a drop-off sent to you, that no one has 
>> picked up.**
>> *The drop-off will expire in 10913 days and 16 hours after which it 
>> will be automatically deleted.**
>>
>> **
>>
>> Any idea why this might be happening on just the reminder e-mails?
>>
>> Thanks,
>>
>> Michael Imlay
>>
>> DELL LOGO
>>
>> Michael Imlay
>>
>> IT & Telecommunications Designer
>>
>> 129 East Government Street
>>
>> Pensacola, FL 32502
>>
>> Direct:  850-332-2084
>> Office:  850-332-5687 x117
>>
>> Cell:       850-737-9219
>>
>> IT at DellConsultingLLC.com <mailto:IT at DellConsultingLLC.com>
>>
>> This email and any files transmitted with it may contain PRIVILEGED 
>> or CONFIDENTIAL information and may be read or used only by the 
>> intended recipient. If you are not the intended recipient of the 
>> email or any of its attachments, please be advised that you have 
>> received this email in error and that any use, dissemination, 
>> distribution, forwarding, printing, or copying of this email or any 
>> attached files is strictly prohibited. If you have received this 
>> email in error, please immediately purge it and all attachments and 
>> notify the sender by reply email or contact the sender at the number 
>> listed.
>>
>>
>> _______________________________________________
>> ZendTo mailing list
>> ZendTo at zend.to
>> http://jul.es/mailman/listinfo/zendto
>
> Jules
>
> -- 
> Julian Field MEng CEng CITP MBCS MIEEE MACM
>
> 'It's very unlikely indeed he will ever recover consciousness, and
>   if he does he won't be the Julian you knew.'
>    - A hospital consultant I proved very wrong in 2007 :-)
>
> www.Zend.To
> Twitter: @JulesFM
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20200714/22f405a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9426 bytes
Desc: not available
URL: <http://jul.es/pipermail/zendto/attachments/20200714/22f405a9/attachment-0001.png>