On 18/06/20 3:00 am, Christopher Barker wrote:
3. String representations and parsing for infinity data (positive and
negative).
yup -- let the bike shedding begin!
My bikeshed suggestions:
DISTANT_FUTURE and DISTANT_PAST for datetimes
MUCH_LATER and MUCH_EARLIER for timedeltas
--
On Tue, Jun 16, 2020 at 11:55 PM Serhiy Storchaka
wrote:
> First we need to solve some problems.
>
> 1. Parsing dates with more than 4-digit year. Note that many external
> implementations do not support such data, so we need a way to restrict
> the data range when convert them to string
I've just updated my implementation to support multiplication and division
of TIMEDELTA_INF, mimicking the behaviour of timedelta and float("inf").
Cheers,
Alex
On Wed, Jun 17, 2020 at 8:26 PM Alexander Hill wrote:
> 1. Dates beyond year aren't a prerequisite for infinite types - I see
>
1. Dates beyond year aren't a prerequisite for infinite types - I see
that as a separate issue. The fact that we can't represent dates between
and infinity doesn't make infinity less useful :)
2 & 3. Yeah, string representation is something that needs to be decided on
- that's a big
Yeah, looks like it had support in principle but just went quiet.
I'd be ok with just having it as a third-party library, but the real value
comes when your data layer supports it directly - psycopg2, ORMs, etc.
That's far more likely to happen if it's built-in.
Thanks for responding!
Cheers,
16.06.20 13:54, Alexander Hill пише:
I’d like to propose support for infinite dates, datetimes and
timedeltas. They're very useful when you need to model ranges with one
or both ends unbounded (e.g. “forever starting from June 15th 2020”).
Without first-class infinite values, you can use
On Tue, Jun 16, 2020 at 06:54:49PM +0800, Alexander Hill wrote:
> Hi all,
>
> I’d like to propose support for infinite dates, datetimes and timedeltas.
Some languages (R comes to mind, if I recall correctly) also support a
"Not A Date" special value. Boost includes a not-a-date-time value:
I think I recall that discussion -- but don't recall how it ended. Did it
just peter out?
Anyway, +1 form me -- I've actually got my own implementation as well. So
it certainly has a use case, and it's really better to have one version in
the stdlib.
I haven't had a chance to review your
