Stefan, the result is correct now
[edwin@ottopedi ~/ICUTest]$ ./a.out Date Formatted with defaults: 20170914 09:40 p.m. Date Formatted with defaults: 14 sep. 2017 Date Formatted with defaults: 14 september 2017 om 21:40:33 CEST Does this mean the problem is in my GNUstep installation? Kind regards, 2017-09-14 18:28 GMT+02:00 Stefan Bidigaray <[email protected]>: > Hi Edwin, > The attached test does something very similar to GNUstep, and you should > get the same answers. Can you check this out and report back? > > To build: > cc test_icu.c `icu-config --ldflags --ldflags-icuio` > > My results: > Date Formatted with defaults: 20170914 12:26 p.m. > Date Formatted with defaults: 14 sep. 2017 > Date Formatted with defaults: 14 september 2017 12:26:33 GMT-4 > > Regards > > On Thu, Sep 14, 2017 at 11:45 AM, Stefan Bidigaray <[email protected]> > wrote: > >> 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
