Misc: - [x] Timestamp.replace should support fold kwarg. ATM the kwarg exists but is ignored. - [x] Timestamp constructor should accept nanosecond kwarg (#18898) (closed by #19889)

Refactoring: - [x] move _nat_strings and _checknull_with_nat to a single canonical location - [x] put OutOfBoundsDatetimeError in a dependency-free util-like module. (#17805) - [x] Possible redundancy between parse_datetime_string and parse_time_string update not redundant. - [x] De-privatize names in tslibs.parsing - [x] cython version of compat for string_types, StringIO - [x] Don't import DateParseError in tslib - [x] de-privatize nattype._checknull_with_nat (closed by #18443)

Check if these need to be exposed or (in some cases) need to exist: - [x] _Period._comparables (closed by #18443) - [x] Timedelta._validate_ops_compat - [x] Timedelta._binary_op_method_timedeltalike - [x] Timedelta._op_unary_method - [x] Timedelta._roundupdate Won't fix/correct-as-is - [x] Timestamp._roundupdate Won't fix/correct-as-is - [x] _Timestamp._get_fieldupdate Won't fix/correct-as-is - [x] _Timestamp._get_named_field - [x] _Timestamp._get_start_end_fieldupdate Won't fix/correct-as-is - [x] lib.arrmap (closed by #18443) - [x] _libs.src.numpy_helper.infer_type

TZ Conversion: - [x] tslib._localize_tso appears to make a handful of unnecessary calls, see #17944 - [x] Is it the case that tslib._localize_tso argument obj will always have obj.tzinfo == None? This is the case in all existing usages. - [x] Inconsistency between tz_convert and tz_convert_single #17734

Offsets: - [x] normalize attr should be relevant for __eq__ #17689 (closed by #21404) - [ ] update docstrings - [ ] Track down meaning behind comment # I suspect this is wrong for *all* of them. in BQuarterBegin.

Timestamp Methods (moved from #17876)- - [x] Timestamp classmethods should return cls, not hard-coded Timestamp - [x] ... if and only if is_timestamp is updated to recognized subclasses. - [x] NaT / timedelta should behave like NaT / Timedelta #17955 - [x] _assert_tzawareness_compat doesn't actually return the declared return typeupdate but declaring it as void leads to build-time error because that mis-matches the except? -1 - [x] #17906 implements Timestamp.timestamp as round(self.value / 1e9, 6) for consistency with datetime method. Are we sure we want to drop nanosecond information? Might it be better to update utcfromtimestamp for round-trip internal consistency? - [x] Timestamp.replace should handle freq #18544 - [x] Timestamp.replace should handle DST gracefully #18319 (closed by #18618)

Follow-Up Cleanup: - [x] Fix camelCase naming in offsets - [x] docstrings for Timestamp.utcnow, utcfromtimestamp, fromtimestamp, combine - [x] ci/lint.sh stricter with pyx files - [x] simplify/correct NaT docstrings - [x] de-privatize _get_rule_month - [x] Possibly remove unique_deltas, asv etc https://github.com/pandas-dev/pandas/pull/18034#discussion_r149657651 update unique_deltas does appear to be more performant than the alternatives. - [x] add types, docstrings, de-privatize in some cases in tslibs.frequencies https://github.com/pandas-dev/pandas/pull/17746#discussion_r150272039, https://github.com/pandas-dev/pandas/pull/17746#discussion_r150321079 - [x] docstring for tslibs.resolution.resolution - [x] consider renaming is_null_datetimelike --> checknull_datetimelike (https://github.com/pandas-dev/pandas/pull/18357#discussion_r151867565) (2021-12-07 is_null_datetimelike has been removed) - [x] check for unit already PANDAS_FR_ns in conversion.ensure_datetime64ns - [x] Remove #noqad unused imports

Decision Making - [ ] Have NaT not subclass datetime? - [x] Wrap datetime.date with Timestamp? Or possible treat it as Period(..., freq="D")? #17965 - [x] Make Resolution singleton or use instance or [...]. See #18034. - [ ] Consider making Timestamp.replace raise instead of returning an imaginary time (https://github.com/pandas-dev/pandas/pull/18618#issuecomment-352285892)

Issues: - [x] check if #17037 is handled by #17640 Update It is not.

Questions: - [ ] Shouldn't pd.Period('2017').day be None instead of 31? #18378

Unsorted - [x] Build warnings for timedeltastruct https://github.com/pandas-dev/pandas/pull/18357#issuecomment-346496628 (closed by #18443) - [ ] Ween off of dateutil internals, specifically import of _timelex in tslibs.parsing. - [x] Period tests for __sub__ with datetimelike https://github.com/pandas-dev/pandas/pull/18524#discussion_r153465607 - [ ] Fix missing tz arg in #18471. - [x] Make sure we aren't comparing tzinfo1 == tzinfo2 as that may be misleading for pytz - [ ] investigate why an "extra layer" is needed in np_datetime.cstring_to_dts - [x] docstrings for np_datetime._string_to_dts, cstring_to_dts - [x] de-privatize frequencies._MONTH_NUMBERS etc, mismatch _MONTHS vs MONTHS

Low Priority: - [x] Set seen_datetime consistently in array_to_datetime #18554

Comment From: jreback

as an FYI, am happy to have you make 1 issue that you create (e.g. this one), that you can then put ToDO items and then check them off.

Comment From: jbrockmendel

FYI most of these are solved locally and are slowly getting pushed back upstream. The main ones on which I need input are a) the tz_convert vs tz_convert_single issue (see discussion in #17734), b) the question about obj.tzinfo in tslib._localize_tso. and c) the BQuarterBegin issue.

Comment From: jreback

for _nat_strings, I think tslibs.parsing is defining these as well as tslibs.nattype

Comment From: WillAyd

@jbrockmendel for the pyx LINT to-do do you need help updating the pyx files? From what I can tell most of the errors there would be simple like E225 missing whitespace operator

Relatively minor but having worked on some pyx files recently including those in lint-diff in the Makefile would be nice. Very clean and easy if we don't need to select a bunch of codes as we currently do in ci/lint.sh

Happy to knock out some of those pyx files if you need help. Let me know.

Comment From: jbrockmendel

I think the E225 errors are for cython pointer arguments &dts which the linter thinks are typos. Do you know of a cython-aware linter? Most times I try to run flake8 on cython it hits a syntax error pretty early and then chokes.

Comment From: WillAyd

My mistake - I just saw all of those errors and assumed they were legitimate, but now I see the caveat. I'm not aware of a cython-aware linter and doubt there is one.

Comment From: WillAyd

Can't claim to have done this before but one of the answers in the below SO article makes me think there's a way to modify setup.cfg to have different matching criteria just for .pyx files, which at the very least could make it easier to consistently apply LINTing to the project whether its called from the Makefile or from ci/lint.sh. Worth a look if there's an appetite to keep that consistent

https://stackoverflow.com/questions/25535599/options-for-linting-cython-code

Comment From: jbrockmendel

Everything actionable has either been addressed or has its own issue. closing.