there are some jQuery based timepickers out there. while using a timepicker could improve the user experience (no need to use the keyboard), many of them are not really useful. but some are. find a good one and integrate it.

suggestions r welcome.

Use case

I want users to be able to insert their birthday. The output I have format to yyyymmdd, limiting the inserted year to atleast 1900.

value.strftime('%Y%m%d')  # yyyymmdd

So date they can enter has to be between 1900 and ~2 years ago.

from datetime import datetime
now = datetime.now()
# Cannot be before 1900, calculate min year
# For now=2017,  min_year=-117
min_year = -now.year + 1900
widget.years_range = (min_year, -2)
widget.update()

After entering a date, the user caused a validation error on another field.

Expected behavior

The date widget renders the same select options for the year as before the validation error.

Observed behavior

The year-options are based on the inserted date. So where my initial range was: 1900-2015
After picking a date in 1986, my range changed to: 1869-1984

Cause

The cause appears to be the logic behind the years property here.

Solution

Seems to me you should never base the options on the inserted year and now should always be datetime.now(). But I cannot oversee the impact at this time.

If I use the z3cform DatetimeWidget without a time:

It will reset it after saving:

The widget shows the wrong weekdays for the each day, which is an issue inherited from collective.z3cform.datetimewidget.

Original issue:
http://code.google.com/p/dexterity/issues/detail?id=272

Original fix:
collective/collective.z3cform.datetimewidget@1acd9b0

I would've just copied the code over, but the code paths have already diverged, so it's a bit more work. So if anyone finds time to do it before I do, thank you! :)

Steps to reproduce:

• Edit an object with more than one datetime widget;
• Set the "wholeDay" field to True
• Save and edit the object again
• All "time" input-fields from all datetime widgets will be hidden

Reason:
The fieldname is not checked in this part of the code
file: /formwidget / datetime / templates / input.pt
tal:root define="whole_day context/whole_day|context/wholeDay|nothing;
required view/required"

https://github.com/plone/plone.schemaeditor/blob/master/plone/schemaeditor/fields.py#L20 depends on interface resolution order to determine which schema to use for IDate (Date field). When plone.formwidget.datetime is not installed, the result will be plone.schemaeditor.schema.IDate -- however, when plone.formwidget.datetime is installed, this lookup breaks. Compatibility needs to be fixed on one or the other of these packages. If it is determined that this needs to be in plone.schemaeditor, I will close this issue here and file a trac ticket on dev.plone.org.

for archetypes widgets - where we have dropdowns - when hour or minute is 0 there is no option-name shown in the dropdowns.

add an option to dx/at widgets to use text input date/time fields instead of the select/dropdown inputs. see http://jquerytools.org/demos/dateinput/index.html for an example.

I'm using plone.formwidget.datetime in a user facing form where the user has to enter his birthday. This is a required field and I marked it as such.

The problem is that plone.formwidget.datetime preselects the first possible date from the options list, which means that the widget comes prefilled. The user doesn't have to enter anything.

I think it would be better if the dates were only preselected if an actual non-empty default value was set. The user would then be required to actually enter a date. The validation would fail if the user never selected anything.

This way, it is possible to have both an empty value and an actual value preselected.

If anyone agrees with me I don't mind implementing this myself.

snippets from archetypes and z3cform widget templates can be factored out and moved into a generic template with macro definitions.

unified templates make it easier tso maintain them. changes are made for all widgets from one place.

the javascript from plone.app.event (hiding the time component for whole_day, hiding the end date for same_day) breaks often becaue of template changes.

I created an EasyForm with a single datetime field. This field is not required. When I submit the form with the datetime field left empty, I get the following exception:

Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module plone.z3cform.layout, line 63, in __call__
Module plone.z3cform.layout, line 57, in update
Module z3c.form.form, line 163, in render
Module Products.Five.browser.pagetemplatefile, line 125, in __call__
Module Products.Five.browser.pagetemplatefile, line 59, in __call__
Module zope.pagetemplate.pagetemplate, line 137, in pt_render
Module five.pt.engine, line 98, in __call__
Module z3c.pt.pagetemplate, line 163, in render
Module chameleon.zpt.template, line 261, in render
Module chameleon.template, line 171, in render
Module aa6bca81f4134407c247edc3cf6064dd.py, line 302, in render
Module five.pt.expressions, line 161, in __call__
Module z3c.form.widget, line 154, in render
Module zope.browserpage.viewpagetemplatefile, line 49, in __call__
Module zope.pagetemplate.pagetemplate, line 137, in pt_render
Module five.pt.engine, line 98, in __call__
Module z3c.pt.pagetemplate, line 163, in render
Module chameleon.zpt.template, line 261, in render
Module chameleon.template, line 191, in render
Module chameleon.template, line 171, in render
Module 98a55ed249bfb07b085d0534cdf2aabe.py, line 151, in render
Module five.pt.expressions, line 154, in __call__
Module five.pt.expressions, line 126, in traverse
Module zope.traversing.adapters, line 142, in traversePathElement
- __traceback_info__: (<DatetimeWidget 'form.widgets.my_datetime'>, 'formatted_value')
Module zope.traversing.adapters, line 42, in traverse
- __traceback_info__: (<DatetimeWidget 'form.widgets.my_datetime'>, 'formatted_value', ())
Module plone.formwidget.datetime.base, line 181, in formatted_value
Module plone.formwidget.datetime.base, line 435, in _dtvalue
Module plone.formwidget.datetime.base, line 292, in _base_dtvalue
ValueError: invalid literal for int() with base 10: ''

- Expression: "w/render"
- Filename:   ... 2.0.1-py2.7.egg/collective/easyform/browser/thank_you.pt
- Location:   (line 21: col 39)
- Source:     <span tal:replace="structure w/render"></span>
                                            ^^^^^^^^
- Expression: "view/formatted_value"
- Filename:   ... py2.7.egg/plone/formwidget/datetime/templates/display.pt
- Location:   (line 6: col 27)
- Source:     ><tal:block condition="view/formatted_value"
                                    ^^^^^^^^^^^^^^^^^^^^
- Arguments:  repeat: {...} (0)
            context: <ImplicitAcquisitionWrapper my-easyform at 0x7f5e8f033d20>
            views: <ViewMapper - at 0x7f5e8d54d910>
            modules: <TraversableModuleImporter - at 0x7f5e9f797510>
            args: <tuple - at 0x7f5ea7f97050>
            nothing: <NoneType - at 0x8f5320>
            target_language: en
            default: <object - at 0x7f5ea7eb7540>
            request: <instance - at 0x7f5e8e996b90>
            wrapped_repeat: {...} (0)
            loop: {...} (0)
            template: <ViewPageTemplateFile - at 0x7f5e9085fdd0>
            translate: <function translate at 0x7f5e8d6f8cf8>
            options: {...} (0)
            view: <DatetimeWidget my_datetime at 0x7f5e8d6f7f90>

From this traceback, it looks like the problem is with plone.formwidget.datetime, and not with collective.easyform.

the codebase serves archetypes and z3cform widgets. but the code is hard to read and understand. one reason is, because this package was glued together from collective.z3cform.datetimewidget and archetypes.datetimewidget.
it could be easier - by refactoring out some methods.

i started the branch utils-module here: https://github.com/collective/plone.formwidget.datetime/tree/utils-module
the tests are failing at this state.
i stopped at this point, because i have to do other stuff first.

i factored out the padded_hour, padded_minute and _padded_value methods into the utils module. i think the AbstractDate* classes in the base module should be like views with less formating code, so that they are less cluttered and easier to read.

while refactoring the tests in plone.formwidget.datetime.tests.test_AbstractDatetimeWidget i was removing some of the test mock code for easier reading. but then i realized that the mocking of methods can be quite flexible (the implementation of the padded methods can be more easily changed). but i think the mocking makes the tests less readable and we should be more explicit in the tests.

also, i like doctests / docmodule for unit testing, like in the utils module. it's a developer documention too.

should we refactor this package? but it's already usable.

what do you think, @kiorky @dokai @taito @regebro @garbas @davisagli ?