stdlib dateformat parsing is inconsistent, creates 32-bit issue

The tl;dr of this is that when julia does DateTime parsing, it tends to cast any resulting int values to Int64 (year, month, day, etc). Specifically on the “u” or “U” dateformat (which is either abbreviated month i.e. jan, or full month name i.e. January) julia will return an Int32 on 32-bit machines as that code path does not cast the result to an Int64.

I have more details in the following link to an issue, but I will copy/paste the important parts here as well

Specifically this line value should be something like value::Int64 . On 32 bit systems, this will return as a 32 bit value and will fail at this function since it expects all inputs to be Int64

I’ll note that the other non lookup conversion values (year, month, day) they get casted to an Int64 so it seems like the text version of the month is the only value that this problem exists for.

A 32-bit value is also returned for DoW conversions as it follows a similar path as the month conversions.

I wasn’t sure if this really warranted a bug issue on github, so I figured I’d bring it here first to see if anybody had any thoughts on it.


Yes. The inconsistency you note is an important one to remedy. They should be cast to the same specific Signed type ( Int64). Where Int or Int32 appears, its likely an oversight.

You should note both the Month and the DoW are forcing Int32s into an Int64 processing context. While you are checking, also reconfirm that the remaining DateTime elements are being treated as Int64s (an Int32 Minute would cause similar issues). Thanks.

Thanks for the reply. I have opened up an issue in the julia github project

I have done some research, and based on what I found I believe that all the other date parsing flags are being converted to Int64 at some point, and only the month and DoW string to integer replacements are affected by this.