ENV: On flame (Gecko-b3429ef.Gaia-c6c6116) and fireE (firee-kk-v2.0-SW2E3-1) Loop version: 1.1 , 2168965 FAST STR: (simulation changing the date of the device) 1.- Make a call to a valid loop ID, but not authenticated, causing one shared url entry. 2.- Changing the date of the device to two days later, check that the number of days left changes from 31 to 29. 3.- Now, repeat step n.1 with that loop ID or another loop ID. ACTUAL RESULT: The new entry in shared links has 29 days left, instead of 31 days left.

yeah, I can reproduce it following the STR... Cristian, can you have a look at it? As you were doing some changes in the locales of these texts, perhaps it can be related... Thanks!

There is not a regression due to locales. The object url is created on server side and it sets the date when the URL expires. IMHO the server should indicate if this expires in x days and the client side will calculate the timestamp according to the date configured in the device. It returns the expiresAt parameter and I would like to know the expiresIn parameter. What do you think Fernando? Could it be feasible? https://github.com/crdlc/loop-server/commit/620f26241dc3ea66684f25a6010683ed83d4e294 (In reply to Maria Angeles Oteo (:oteo) from comment #1) > yeah, I can reproduce it following the STR... Cristian, can you have a look > at it? As you were doing some changes in the locales of these texts, perhaps > it can be related... Thanks!

You are right, this is due to we are keeping locally the expiration date from the server when we create the URL so if the local time changes, the difference between local and expiration time changes too,so not too much we can do here. We already talked about this issue in bug 1048842 that we resolve as won't fix, that's what I think we should do in this bug, but waiting for triage to decide it.

Verified on FireE (comercial build v2.0) and Flame 2.0, Loop v1.1, 4212078