You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AIX is simple - it just needs to be pointed to /usr/share/lib/zoneinfo instead of every other Unix's /usr/share/zoneinfo.
i is much trickier - it lacks zoneinfo entirely; setting TZ to an explicit value. System values can be found with WRKOBJ QSYS/*ALL *TIMZON or WRKTIMZON. Some ideas:
Generate a zoneinfo database from the system time zone values on the native side. This means no framework changes and system integration, but a program to generate values will need to be maintained.
Modify the framework to call into the ILE and convert time zone values there. Will require either ugly changes in the middle of normal code, or perhaps even our own framework profile if we have to keep adding these.
The nice thing about these two approaches is that they'll behave in line with the rest of the system, operating on the same values.
Ship a copy of zoneinfo with our builds and point the library to use that. Portable, but a bit hackish.
The text was updated successfully, but these errors were encountered:
I think the reasonable course of action would be to upstream a workable patch for AIX, (for the sake of CI) and for our builds, patch TimeZoneInfo.cs and bundle the IANA database and tools.
AIX is simple - it just needs to be pointed to
/usr/share/lib/zoneinfo
instead of every other Unix's/usr/share/zoneinfo
.i is much trickier - it lacks zoneinfo entirely; setting TZ to an explicit value. System values can be found with
WRKOBJ QSYS/*ALL *TIMZON
orWRKTIMZON
. Some ideas:Generate a zoneinfo database from the system time zone values on the native side. This means no framework changes and system integration, but a program to generate values will need to be maintained.
Modify the framework to call into the ILE and convert time zone values there. Will require either ugly changes in the middle of normal code, or perhaps even our own framework profile if we have to keep adding these.
The nice thing about these two approaches is that they'll behave in line with the rest of the system, operating on the same values.
Ship a copy of zoneinfo with our builds and point the library to use that. Portable, but a bit hackish.
The text was updated successfully, but these errors were encountered: