YY maps 2018 to 20

Hi there, I’m trying to standardise a bunch of records which can contain the patterns dd/mm/yyyy, d/mm/yy etc.

When using the example input of “15/01/2019”

print arrow.get("15/01/2019", ["D/M/YY","D/M/YYYY"]).format('YYYY-MM-DD') outputs 2020-01-15, which seems to use “D/M/YY”. I would expect it to be ignored, since it doesn’t fit with the pattern of the data provided

Currently I’m getting around this by swapping around the array, but i’m not feeling great about the fragility here. print arrow.get("15/01/19", ["D/M/YYYY","D/M/YY"]).format('YYYY-MM-DD')

Suggestions: 1. If YY is specified, it looks for YY:YYYY (\/[0-9]{2,4}). If the pattern extends without a delimiter up to 4 characters, it’s treated as valid

If I could supply ,"D/M/YY$" I’d have a lot more confidence that the string will be correctly processed, regardless of where the pattern exists in the list.

If YY is specified, it strictly looks for YY. If the pattern extends without a delimiter, it’s treated as invalid and the pattern is skipped.

Please let me know if you need any more information here! Cheers, Adam

[systemcatch]

Hey Chris, thanks for pointing that out! I thought I’d checked that in the initial bug report but after trying the use cases we’ve been working with here, the $ seems to solve them all. So is that just a small amendment to the docs then? Cheers, Adam From: Chris [e-mail] Reply-To: crsmithdev/arrow [e-mail] Date: Friday, 15 February 2019 at 10:24 am To: crsmithdev/arrow [e-mail] Cc: Adam Rudd [e-mail], Mention [e-mail] Subject: Re: [crsmithdev/arrow] YY maps 2018 to 20 (#560) Quick follow up I was messing about with your suggestion number 2.

arrow.get(“15/01/2019”, [“D/M/YY”,“D/M/YYYY”]) <Arrow [2020-01-15T00:00:00+00:00]> arrow.get(“15/01/2019”, [“D/M/YY$”,“D/M/YYYY”]) <Arrow [2019-01-15T00:00:00+00:00]> arrow.get(“15/01/2019”, [“D/M/YY$”,“D/M/YYYY”]).format(‘YYYY-MM-DD’) ‘2019-01-15’ It seems to already work!? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#560 (comment)>, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXgIFDoadVhLAa-_PaxsfN3lU_1CR2X3ks5vNfAhgaJpZM4aHHzY. … ________________________________ This email and any attachment are confidential. If you are not the intended recipient, please notify MYOB by reply email and delete this email. Please note that you must not access or use this email or any information in it. MYOB accepts no liability for viruses in this email or in any attachment to it.

Yeah I guess an update to the docs is order. To be honest I’m kinda surprised it works, probably to do with special regex characters now being handled better.

[adam-rudd-myob]

Hey Chris, thanks for pointing that out! I thought I’d checked that in the initial bug report but after trying the use cases we’ve been working with here, the $ seems to solve them all. So is that just a small amendment to the docs then?

Cheers, Adam

From: Chris [e-mail] Reply-To: crsmithdev/arrow [e-mail] Date: Friday, 15 February 2019 at 10:24 am To: crsmithdev/arrow [e-mail] Cc: Adam Rudd [e-mail], Mention [e-mail] Subject: Re: [crsmithdev/arrow] YY maps 2018 to 20 (#560)

Quick follow up I was messing about with your suggestion number 2.

arrow.get(“15/01/2019”, [“D/M/YY”,“D/M/YYYY”])

<Arrow [2020-01-15T00:00:00+00:00]>

arrow.get(“15/01/2019”, [“D/M/YY$”,“D/M/YYYY”])

<Arrow [2019-01-15T00:00:00+00:00]>

arrow.get(“15/01/2019”, [“D/M/YY$”,“D/M/YYYY”]).format(‘YYYY-MM-DD’)

‘2019-01-15’

It seems to already work!?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/crsmithdev/arrow/issues/560#issuecomment-463843651, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXgIFDoadVhLAa-_PaxsfN3lU_1CR2X3ks5vNfAhgaJpZM4aHHzY.

---

This email and any attachment are confidential. If you are not the intended recipient, please notify MYOB by reply email and delete this email. Please note that you must not access or use this email or any information in it. MYOB accepts no liability for viruses in this email or in any attachment to it.