diff options
| author | Robot Odoo <xmo+roboto@odoo.com> | 2018-11-22 13:02:21 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-11-22 13:02:21 +0100 |
| commit | ba8bac8f9884bc5d8962e0ba22ed2f4789dd98bf (patch) | |
| tree | 0922bb81643b9aad520d22dd154da6c467cce759 /addons/web_editor/static/lib/summernote/src/js/EventHandler.js | |
| parent | f68c5261f9209aba7d8f19a33f1892d863c3c448 (diff) | |
| parent | 752545553495dc9cec73714989b8f5e610825bbc (diff) | |
[FIX] web: search input date in another timezone
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we use the string representation of
the moment object in search_inputs (i.e 2018-02-12T00:00:00 UTC), to create a new one
*BUT* we create it with a date format that excludes the time from being interpreted.
Also, the resulting moment object in this case is not flagged as UTC anymore
OPW 1903224
closes odoo/odoo#28542
Diffstat (limited to 'addons/web_editor/static/lib/summernote/src/js/EventHandler.js')
0 files changed, 0 insertions, 0 deletions
