Parse 2-digit year

[malthe]

When I use [year repr:last_two] I get the following error from OffsetDateTime::parse:

Unable to parse date: the Parsed struct did not include enough information to construct the type

Presumably because there is ambiguity whether this is 1634 or 2034.

How can I add information that this is always 2000's – ?

[jhpratt]

So it's not quite as simple as it could be, admittedly. I need to add a method that would permit easier manual control over values.

For now, you'll have to go through the Parsed struct yourself. You can do this by using Parsed::parse_items, which returns the raw Parsed instead of the final value. You can then modify this (in your cast using .year_last_two() and .set_year()/.with_year(). Once you've done that, you can call .try_into() or OffsetDateTime::try_from(val).

[malthe]

I just realized that you also cannot just add 100 years, just like you can't add one month.

Perhaps an optional prefix: [year prefix:19].

From reading the source those modifiers are specific to each component – so this could work right?

[jhpratt]

They are indeed component-specific. While a prefix works for some cases, it doesn't for others. One RFC (I forget which) requires them being treated as between 1970 and 2069. It's doubly difficult because modifiers are all enums. While not a technical requirement, I'd like to keep it that way.

[malthe]

Perhaps there are few enough case that it would be possible to enumerate them all, e.g. 1970-2069 (this would work for me).

But in that case – but this would not be an enum – might also just have [year base:1970]. Wouldn't that be fairly clear to the user – and it is an integer, not some string-based prefix.

[jhpratt]

Assuming a 16 bit integer, that would double to 32 bits when the Option is included (there's a way to avoid this but it hasn't hit MSRV yet). That's a reasonably large amount to store something that is otherwise ambiguous. But at the same time I'm not at all a fan of a 100+ variant enum for obvious reasons.

I'll consider it, but right now I'm leaning against it. At a minimum it'll be a while, as I have a number of high-impact things I'm working on currently.

[malthe]

Since you control the internal representation I think you could do with some bit-hacking here. I think it would be totally fair to constrain the interface to a value between 1900 and 2000 for example. You can express that with 8 bits including the "option bit".