Project

General

Profile

Actions

Bug #6197

closed

AmbiguousTimeError when searching events

Added by Jan Mach over 4 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Development - GUI
Target version:
Start date:
01/20/2020
Due date:
% Done:

100%

Estimated time:
To be discussed:

Description

Following error was encountered during daylight saving time switch period:

Message type: ERROR
Location:     /var/mentat/venv/lib/python3.7/site-packages/flask/app.py:1891
Module:       app
Function:     log_exception
Time:         2019-11-03 16:32:16,658

Message:

Exception on /events/dashboard [GET]
Traceback (most recent call last):
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/app.py", line 2446, in wsgi_app
    response = self.full_dispatch_request()
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/app.py", line 1951, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/app.py", line 1820, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/app.py", line 1949, in full_dispatch_request
    rv = self.dispatch_request()
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/app.py", line 1935, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/var/mentat/venv/lib/python3.7/site-packages/flask_principal.py", line 199, in _decorated
    rv = f(*args, **kw)
  File "/var/mentat/venv/lib/python3.7/site-packages/flask_login/utils.py", line 261, in decorated_view
    return func(*args, **kwargs)
  File "/var/mentat/venv/lib/python3.7/site-packages/flask/views.py", line 89, in view
    return self.dispatch_request(*args, **kwargs)
  File "/var/mentat/venv/lib/python3.7/site-packages/hawat/base.py", line 1502, in dispatch_request
    form = self.get_search_form(flask.request.args)
  File "/var/mentat/venv/lib/python3.7/site-packages/hawat/blueprints/events/__init__.py", line 355, in get_search_form
    return EventDashboardForm(request_args, meta = {'csrf': False})
  File "/var/mentat/venv/lib/python3.7/site-packages/wtforms/form.py", line 212, in __call__
    return type.__call__(cls, *args, **kwargs)
  File "/var/mentat/venv/lib/python3.7/site-packages/flask_wtf/form.py", line 88, in __init__
    super(FlaskForm, self).__init__(formdata=formdata, **kwargs)
  File "/var/mentat/venv/lib/python3.7/site-packages/wtforms/form.py", line 278, in __init__
    self.process(formdata, obj, data=data, **kwargs)
  File "/var/mentat/venv/lib/python3.7/site-packages/wtforms/form.py", line 132, in process
    field.process(formdata)
  File "/var/mentat/venv/lib/python3.7/site-packages/wtforms/fields/core.py", line 290, in process
    self.process_formdata(self.raw_data)
  File "/var/mentat/venv/lib/python3.7/site-packages/hawat/forms.py", line 428, in process_formdata
    dt_local  = localtz.localize(dt_naive, is_dst = None)
  File "/var/mentat/venv/lib/python3.7/site-packages/pytz/tzinfo.py", line 363, in localize
    raise AmbiguousTimeError(dt)
pytz.exceptions.AmbiguousTimeError: 2019-10-27 02:00:00
Actions #1

Updated by Pavel Kácha about 3 years ago

  • Assignee deleted (Jan Mach)
Actions #2

Updated by Rajmund Hruška almost 2 years ago

  • Status changed from New to Resolved
  • Assignee set to Rajmund Hruška
  • Target version changed from Backlog to 2.10
  • % Done changed from 0 to 100
  • To be discussed deleted (No)

Should be fixed in 71a4916a.

Actions #3

Updated by Pavel Kácha almost 2 years ago

  • Status changed from Resolved to Feedback

Do I understand correctly that time in ambiguous interval is now reported as error?
I don't think it's right.

When time shift changes in october from CEST to CET, in 3:00 time jumps to 2:00. So times between 2:00 and 3:00 (inclusive) do exist in both CET and CEST, and without specifying the timezone it is not clear which is meant. How do I now enter 2:30 CEST?

I guess the simplest solution is to choose CET or CEST consistently (always sooner one, always later one or always the same one) in case of ambiguity.

Actions #4

Updated by Rajmund Hruška almost 2 years ago

Pavel Kácha wrote in #note-3:

Do I understand correctly that time in ambiguous interval is now reported as error?
I don't think it's right.

When time shift changes in october from CEST to CET, in 3:00 time jumps to 2:00. So times between 2:00 and 3:00 (inclusive) do exist in both CET and CEST, and without specifying the timezone it is not clear which is meant. How do I now enter 2:30 CEST?

I guess the simplest solution is to choose CET or CEST consistently (always sooner one, always later one or always the same one) in case of ambiguity.

There are two classes for datetime fields: DateTimeLocalField and SmartDateTimeField. As far as I am aware, DateTimeLocalField is not used at all so I didn't bother to handle the DST and I just caught the exceptions. The other class is actually used and there is only one method where this exception can occur. This is the one used in the forms and there I handle DST as you described in your simple solution. The other method of SmartDateTimeField where I catch the exception doesn't really need handling of those exception (I have realized this while writing this comment) as it is working with UTC time which doesn't have DST.

Actions #5

Updated by Pavel Kácha almost 2 years ago

  • Status changed from Feedback to Resolved

Rajmund Hruska wrote in #note-4:

There are two classes for datetime fields: DateTimeLocalField and SmartDateTimeField. As far as I am aware, DateTimeLocalField is not used at all so I didn't bother to handle the DST and I just caught the exceptions. The other class is actually used and there is only one method where this exception can occur. This is the one used in the forms and there I handle DST as you described in your simple solution. The other method of SmartDateTimeField where I catch the exception doesn't really need handling of those exception (I have realized this while writing this comment) as it is working with UTC time which doesn't have DST.

I see. Sorry, I missed the chunk from 541 onward. Move on, nothing to see here.

Actions #6

Updated by Rajmund Hruška almost 2 years ago

  • Status changed from Resolved to In Review

Merged into devel and deployed on mentat-alt.

Actions #7

Updated by Pavel Kácha almost 2 years ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF