Systems with signed 32bit unix from 1970 will soon get Y2K38 problems, this one uses unsigned from 2000, so a embedded system using it will get plenty of life.
I did not look at any other code examples as I did not want to get "bad" influences.
Mine is fast and uses no multiplications/division and no fractions, pasm have cmpsub so that would be even faster.

Just to be pedantic -- your routine converts "solar" seconds to date, not SI (or standard UTC) seconds. In other words, you're ignoring leap seconds. Which is probably unavoidable for an embedded system!

(Sorry, you hit on one of my pet peeves -- lots of people think Unix time_t and similar timestamps count "seconds since the epoch", but in fact they actually count 86400*"days since the epoch", and the two are not the same -- not all days have 86400 seconds.)

Feb7 2136 there will be cursing , but is anything build this decade still around then? pcb probably turned in to sand, capacitors have dried up.

You can also do local time:

rtc.zone = 9.5*3600; // signed long Adelaide Australia.
//rtc.zone = -5*3600; // signed long New York USA.
seconds_to_rtc(seconds + rtc.zone);

And it's up to user to adjust rt.c.zone ±3600 on the dst-dates.

seconds could be a #define to directly pointing to counter register,
or a function that merge a much faster running counter like 8192Hz rightshifted >>13 and adding to it a software counter that rollover IRQ have been adding upper values to.

So what is best is to have a que message system, that you call to insert a time and event flag and it sorts them. (eg. a rtc alarm)
As you could then insert the 2am/3am DST dates as a event.
Though there are no CCR register and IRQ's for counters on a P1 and waitcnt only taps in on system counter.

leap seconds, leap smear is probably safer, Google did that last time on Dec31 2016 over a 10hr timespan.
You should use a timeserver that gives you seconds from 2000 that don't include leap seconds as actually seconds counted.
Or base your system time on GPS time, it was zero at ( Jan6 ?) 1980 and since it is not perturbed by leap seconds GPS is now ahead of UTC by 18 seconds.

Are leap-smears still seconds added to the seconds-between-two-dates?
quote:
The irregularity and unpredictability of UTC leap seconds is problematic for several areas, especially computing.
For example, to compute the elapsed time in seconds between two given UTC past dates requires the consultation of a table of leap seconds, which needs to be updated whenever a new leap second is announced.
Moreover, it is not possible to compute accurate time intervals for UTC dates that are more than about six months in the future.

Two timescales that do not follow leap seconds are already available, International Atomic Time (TAI) and Global Positioning System (GPS) time
Instead of inserting a leap second at the end of the day, Google servers implement a leap smear, extending seconds slightly over a time window prior to the leap second.
Amazon has announced it would follow a similar, but slightly different, pattern for the introduction of the June 30, 2015 leap second,leading to another case of the proliferation of timescales.

Following ZIGBEE way of doing is probably best, It synchronize itself with NTP UTC, so that should include leap seconds.
But if not syncing up on Jan1 or July1 (two dates most likely to just had a leap second) and it runs of a hardware rtc it will be a second off until next sync.

And where does it store leapsecond lookup table?, so how does ZigBee handle leapseconds when its trying to calculate dates?, I guess that is up to programmer?

---32bit and unsigned unless noted---
Time 0x0000 R The current time, in UTC 2000 (seconds since Jan 1, 2000).
Time Status 0x0001 R Bitmap representing the the synchronization state of this time server.
Time Zone 0x0002 RW User-settable, signed offset from UTC (in seconds) representing the local time zone. (signed)
Daylight Savings Start 0x0003 RW User-settable UTC of when daylight savings time starts for the current year.
Daylight Savings End 0x0004 RW User-settable UTC of when daylight savings time ends for the current year.
Daylight Savings Shift 0x0005 RW User-settable, offset from standard time (in seconds) while daylight savings is in effect. (signed)
Standard Time 0x0006 R The standard time of the local device (seconds since Jan 1, 2000), after adjusting for the time zone.
Local Time 0x0007 R The local time of the local device (seconds since Jan 1, 2000), after adjusting for the time zone and daylight savings

leap second is really mean as it's so random, who cares that sunrise is off by a second?

Why not
1: Just always add two leap seconds to the leapday Feb29, in the last 26 years the average have been 2.17yrs between a added leap second.
OR
2: Use a leap-minute every 100 years, on Jan-1 2100 everyone gets an extra minute of sleep.

In November 2015 it was again decided to continue using leap seconds, pending further study and consideration at the next conference in 2023.