I'll come up with a test for ICU and post it here. I'll make sure to use the same functions used by GNUstep to verify.
I'm still betting the problem is in your ICU installation. The GNUstep code is a thin layer on top of ICU, it's unlikely that the problem lies there. I'm not saying impossible, just unlikely. On Sep 14, 2017 11:38, "Edwin Ancaer" <[email protected]> wrote: > Stefan, > > I did, and the test returns the same wrong results: > > 2017-09-14 17:26:09.914 DateFormatter[80496:100318] the date as date > object 2017-09-14 17:26:09 +0200 > 2017-09-14 17:26:09.953 DateFormatter[80496:100318] Dateformatter defaults > 2017-09-14 17:26:09.970 DateFormatter[80496:100318] DateFormatter > timezone: Europe/Brussels > 2017-09-14 17:26:09.986 DateFormatter[80496:100318] DateFormatter > locale: nl_BE > 2017-09-14 17:26:10.003 DateFormatter[80496:100318] DateFormatter > datestyle: 0 > 2017-09-14 17:26:10.020 DateFormatter[80496:100318] DateFormatter > timestyle: 0 > 2017-09-14 17:26:10.023 DateFormatter[80496:100318] Date formatted with > defaults 20170914 05:26 p.m. > 2017-09-14 17:26:10.027 DateFormatter[80496:100318] DateFormatter: Date -> > NoStyle, Time -> MediumStyle > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > timezone: Europe/Brussels > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > locale: nl_BE > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > datestyle: 0 > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > timestyle: 2 > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] Date formatted with > style 20170914 05:26 p.m. > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter: Date -> > LongStyle, Time -> LongStyle > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > timezone: Europe/Brussels > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > locale: nl_BE > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > datestyle: 3 > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] DateFormatter > timestyle: 3 > 2017-09-14 17:26:10.028 DateFormatter[80496:100318] Date formatted with > style 20170914 05:26 p.m. > > Could i run a C-program that formatted the date with locale nl and > conclude > - the problem is in my ICU installation if the result of the program is > wrong? > - the problem is in my GNUstep installation if the result of the program > is OK? > > Kind regards > > 2017-09-14 17:05 GMT+02:00 Stefan Bidigaray <[email protected]>: > >> Hi Edwin, >> From everything you've said so far, the problem doesn't seem to be in >> GNUstep. The method you are using would return nil if ICU wasn't installed. >> Additionally, the return value is what you'd expect from the en_US_POSIX >> locale, the default in FreeBSD. >> >> With that in mind, have you tried explicitly setting the formatter's >> locale using the -setLocale: method? It's possible your setup is falling >> back to the systemLocale, which would be a separate problem. >> >> Have you tried running the test I attached in my previous email? >> >> Regards >> >> On Sep 14, 2017 10:38, "Edwin Ancaer" <[email protected]> wrote: >> >>> Hello, >>> >>> I return from holidays that have been haunted by this problem :-). >>> >>> I asked about libicudata.so on the freebsd list. The answer was " >>> >>> >>> *devel/icu is built --with-data-packaging=archive which means the data >>> ends up in icudt* file e.g., $ pkg info -l icu | fgrep icudt | xargs du -Ah >>> 25M /usr/local/share/icu/58.2/**icudt58l.dat*" >>> >>> We compared the necessary ICU libraries and they all are present at my >>> side, with more or less equal sizes. >>> >>> In the config.log file for gnustep base, I found: >>> ... >>> HAVE_GNUTLS='1' >>> *HAVE_ICU='1'* >>> HAVE_INET_NTOP='yes' >>> HAVE_INET_PTON='yes' >>> HAVE_LIBDISPATCH='1' >>> HAVE_LIBXML='1' >>> HAVE_LIBXSLT='1' >>> HAVE_MDNS='0' >>> HAVE_OBJC_SYNC_ENTER='yes' >>> ... >>> >>> This seems to indicate ICU is used. Just to be sure, I added >>> >>> #if GS_USE_ICU == 1 >>> NSLog(@" GS USE ICU == 1"); >>> #endif >>> >>> to my program, and effectively, the display appeared: >>> >>> 2017-09-14 11:04:41.625 TM1[79500:100088] GS USE ICU == 1 >>> >>> I tried debugging, but from a recent conversation on this list, it seems >>> I need a port gdb80, that is not present in my FreeBSD 11.0 ports >>> directory (have got gdb and gdb66). >>> >>> I must be missing something obvious, but for now, I'm rather stuck. >>> Problems like this make one feel utterly stupid. >>> >>> Would you have any suggestions left? >>> >>> (I already reinstalled the icu and gnustep base ports, no errors >>> detected, no change in the result). >>> >>> Kind regards, >>> >>> Edwin. >>> >>> _______________________________________________ >>> Discuss-gnustep mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>> >>> > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
