What are the steps to reproduce your issue?

1. Install "stock"
2. Go to Inventory/Inventory Overview/Internal Transfer
3. Create new record and set manually a date with year < 1000 like "0008-10-10 18:35:00"
4. Save
What is currently happening?

An error arises when saving the record, and it is then no longer
possible to reopen the records or any view containing it.
This also prevents us from correcting the date to no longer have the error
Why is this happening?

The root cause is an inconsistency in `strftime` for years < 1000 [1, 2]. To take it into
account, a zero-padding is needed in the DateTime parser.
How to fix the bug?

The missing padding is added.

However, such dates lead to problematic behaviors in Python:

```
DT_FORMAT = "%Y-%m-%d %H:%M:%S"
new_date = "0008-02-05 18:10:10"
datetime.strptime(
    datetime.strptime(
        new_date, DT_FORMAT
    ).strftime(DT_FORMAT),
    DT_FORMAT
)
```

This raises:
```
ValueError: time data '8-02-05 18:10:10' does not match format '%Y-%m-%d %H:%M:%S'
```

As of today there was no reported business cases where dates with year < 1000 would be
necessary. Therefore, we limit the range to years >= 1000.
[1] https://bugs.python.org/issue13305
[2] https://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior

opw-2408260

closes odoo/odoo#62818

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

This commit adds smart date inputs for date and datetime fields.

The goal of smart date input is to provide the user some shortcuts
when setting dates.

The rule is [+-]\d+[dwmy]?
So we can enter inputs like:
  +3  to have today + 3 days
  -2w to have today - 2 weeks
  +1y to have today + 1 year
  +5m to have today + 5 months
  -4d to have today - 4 days

closes odoo/odoo#55602

Task: 2270347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Before this commit, user could not selecta a date before year 1900.
This was an historical limitation due to python < 3.2 that didn't
support dates before 1900.

After this commit, user can select any date, user can select any
date from 01/01/0001.

taskID: 2166761
Fixes #41788
Closes #43055

closes odoo/odoo#51406

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>

This commit adds noLeadingZeroHour option to formatFloatTime.
The noLeadingZeroHour option can be used to format the value
like 1:30 instead of 01:30

This format behaviour is wanted for fields in web_grid module.

Task 2261853

closes odoo/odoo#52217

Related: odoo/enterprise#10870
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Hardik Prajapati <hap@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>

Before this commit the % symbol was part of the input. We could write a
value with the % symbol to divide the value by 100 (50% = 0.5, 50 = 50)

This commit removes the % symbol from the input and adds it in a span
after the input so we do not need to write the % symbol anymore.

The value from the input will be saved as $value / 100 in database.

task-2065078

closes odoo/odoo#43995

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998;  02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.

In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.

opw-2070464
opw-2070931

closes odoo/odoo#37095

Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

When using the datepicker with norwegian locales, the dates are
correctly formatted using the norwegian locale but the name of
the months are shown in english. This cause a date validation
error and thus it is not possible to change the date.

tempusdominus.js uses moment.js to deal with dates, it sometimes
copies/creates some and set their option according to the ones
given at instantiation time and fallbacks on default options for
that are not set.

opw-1922437

closes odoo/odoo#30276

When a percentage if formatted, the decimal separator used is always
`.`, while it should be the decimal separator of the language.

opw-1908220

closes odoo/odoo#30030

The format function was missing for the percentage widget type, so
`field_utils.parse[this.formatType]` (see [1]) resolved as
`undefined` which is not a function and so raised an error when
the user was trying to update the field.

This PR add that parsing function. Both `xx%` and `0.xx` are
understood by the parser and resolve to the correct float value.

opw-1895979

[1] https://github.com/odoo/odoo/blob/e220721a8ee80c02fe5aba5ed8c9f3f4ae54ea97/addons/web/static/src/js/fields/abstract_field.js#L399

closes odoo/odoo#28431

A recent modification of the float and integer
formatters allowing the rendering to be human readable
causes a bug in the percentage formatter for large values.
The reason is that the latter formatter uses formatFloat (wich can
now produce 'numbers' like 3k) and then parse the result. In the case
of 3k an error is raised since 3k is not recognized as a true number.

This fixes avoid to parse the number in case it has been formatted
to be 'readable'. Note that the parsing was essentially used
to produces better percentages like 10% instead of 10.00%.
This is not necessary in our case since utils.human_number takes care
of the unwanted (not all) decimals for us (the original number is always
rounded by utils.human_number).