strpmarstime - basic implementation complete

Using musl as a reference, I’ve completed an.. implementation, of strpmarstime. Yesterday I must’ve placed my energy wrong because I just wasn’t super motivated and didn’t do as much coding.

Anyway:

strpmarstime is the inverse of strfmarstime, taking a date-time formatted string and given its format, entering those values into a mars_tm struct.

Everything made sense, mostly. There are still some areas of code I need to comment and reread to make sure I understand what is going on. But after strfmarstime, it isn’t too crazy.

As usual, it does the things for string parsing, like str++ to move to the rest of the string’s characters, then it parses by item.

In order to find values, I think that the calculations sort of estimate the character location of the number range, and then we import it.

Challenges

nl_langinfo

Once again, I found myself in a situation where musl can lookup strings to match values like day and month names via numerical item addresses with nl_langinfo, but I cannot (as this is not a “standard” item index). Musl is able to use this item address to iterate through the list of potential matches, which is easy to do in common goto routines.

For me, I had to basically make a pointer to an array of char* (so I had char**, once I figured it out), that was the “iteration_array”. Depending on the format, it would check the array for the match. The main confusing thing was really just the pointers. Spent about 10 minutes fighting with compiler errors until I figured it out with the help of stackoverflow and Google’s AI.

By the way, using nl_langinfo_l, which I did in strfmarstime, does not exist in locale.h by default on macOS, it’s in xlocale.h, so I made a small configure define this morning to take care of that.

The vague formats

There are several ways of determining what # week of year we are in. One format says it’s the week with at least four days, and starts indexing at like, 1 I think? And then there are a few others? I can’t remember off the top of my head.

Because there are no clear answers, I (and musl) have left these formats as “parse only”.

This really impacts week number formats, which, I guess makes sense, because if you only have that, who knows what year you are in, and how many days are in the first full “week”, however you define that.

Timezones

Skipped for now, as I have yet to take care of this, and I think some proposed timekeeping systems actually don’t do the standard one-hour intervals.. I need to look into it.

Future

Welp, it’s off to testing and verification. Yay!