Lines Matching refs:fromutc
145 _Py_IDENTIFIER(fromutc);
3742 "fromutc: argument must be a datetime");
3746 PyErr_SetString(PyExc_ValueError, "fromutc: dt.tzinfo "
3755 PyErr_SetString(PyExc_ValueError, "fromutc: non-None "
3764 PyErr_SetString(PyExc_ValueError, "fromutc: non-None "
3794 PyErr_SetString(PyExc_ValueError, "fromutc: tz.dst() gave "
3853 {"fromutc", (PyCFunction)tzinfo_fromutc, METH_O,
4058 "fromutc: argument must be a datetime");
4062 PyErr_SetString(PyExc_ValueError, "fromutc: dt.tzinfo "
4089 {"fromutc", (PyCFunction)timezone_fromutc, METH_O,
6280 /* Attach new tzinfo and let fromutc() do the rest. */
6951 Now we can explain tz.fromutc(x). Let's assume it's an interesting case
7113 In any case, it's clear that the default fromutc() is strong enough to handle
7119 pretty bizarre, and a tzinfo subclass can override fromutc() if it is.