ISO weeknumber

[hdrlux]

As a newbie to Arduino, I didn't find support for ISO weeknumbers in AceTime.

I made up something, inspired by a very old Excel formula. The coding is ugly, maybe someone can transform it to something nice in the library :)

`//weeknumber ONLY valid for Mon=1..Sun=7 datelibrary, works for any Epoch date

LocalDate now = LocalDate::forEpochSeconds(t); //convert DateTime to Date

byte WeekNumber = 0;

acetime_t NowDay = now.toEpochDays(); //daynumber: now

byte NowWD = now.dayOfWeek(); //dayofweek now

acetime_t CloseThu = NowDay - NowWD + 4; //daynumber: closest Thursday from now

int WeekYear = LocalDate::forEpochDays(CloseThu).year(); //Year for ISO Weeknumber, may be different in first or last week

acetime_t YJ4Day = LocalDate::forComponents(WeekYear, 1, 4).toEpochDays(); //daynumber: Year-Jan-4

byte YJ4WD = LocalDate::forEpochDays(YJ4Day).dayOfWeek(); //dayofweek

int DayWS = NowDay - YJ4Day + YJ4WD - 1; //Day in weeksystem [0..370]

WeekNumber = (DayWS / 7) + 1; //ISO Weeknumber`

The current versions of Excel have build-in support for ISOWEEKNUM, generated a list for year 2020-2030 and checked the output of the Arduino.

[bxparks]

The ISO Week Date is so complicated (https://en.wikipedia.org/wiki/ISO_week_date), it makes my head hurt. I believe this will require a new class, because if I understand it, a given Gregorian date (y, m, d) (represented by LocalDate) can be shifted into the previous ISO year or the next ISO week year, depending when that date falls in the first week or last week of the year. So we would probably need a new class like:

class IsoWeekDate {
  public:
    // Constructor
    IsoWeekDate(int16_t year, uint8_t weekNumber, uint8_t weekDay);

    // Create from LocalDate
    static IsoWeekDate forLocalDate(const LocalDate& ld);

    // Convert to LocalDate
    LocalDate toLocalDate();
    ...
};

(This design assumes that LocalDate is the more fundamental, lower-level class than IsoWeekDate so the dependency goes from IsoWeekDate to LocalDate.)

I think the wiki page has the necessary formulas, but I only skimmed over it. Half the work is decoding the formulas in the wiki page. The other half the work is writing the unit tests to make sure all the edge cases are handled properly.

In terms of prioritization, I'll be honest and say that I am not motivated to spend my time on this. I have never used ISO Week Date, so it's a lot of work for something that I will probably never use. I might be persuaded to accept a PR, but reviewing code as complicated as this is also a lot of work. Let's just say that the higher the quality of the submitted code and the more extensive the unit tests, the higher the chances of me looking at it.

[bxparks]

Thinking about this some more, I have concluded that this functionality does not belong in AceTime. The primary purpose of AceTime is to provide timezone conversions using the IANA TZ database. The ISO Week Date feature is not related to that purpose, and would be a distraction.

I suggest that you create a separate library for this feature. Call it the "IsoWeekDate" library. And it can be as simple as just 2 functions. You can write it in C or C++. The function signatures in C would be:

void gregorianDateToIsoWeekDate(
  int16_t year, uint8_t month, uint8_t day, 
  int16_t *isoYear, uint8_t *isoWeekNumber, uint8_t *isoWeekDay);

void isoWeekDateToGregorianDate(
  int16_t isoYear, uint8_t isoWeekNumber, uint8_t isoWeekDay, 
  int16_t *year, uint8_t *month, uint8_t *day);

[hdrlux]

Thanks for the reply, I will stick with my solution for now. I have never done anything in C, just programming by example scripts and re-use code snippets from the internet.

For my project I only need to display the correct ISOWeekNumber on a wallclock in the format "W52". The supply chain the company is in [suppliers & customers] do all planning and reporting in weeks, so it is nice to have a feeling for the current week next to current date.

Your thoughts about transforming a ISOweek back to Gregorian never crossed my mind, that is to complex indeed. I use AceTime because the wallclock is stand-alone and syncs with GPS in UTC, and displays the local date/time with correct DST.

[hdrlux]

First attempt to make a library, that converts epochseconds to ISOWeek number.

AceTimeISOWeek v0.1

[bxparks]

Gave you some feedback at https://github.com/hdrlux/AceTimeISOWeek/issues/1