There is at the moment a patch for NSDateFormatter in our bug tracker: http://savannah.gnu.org/bugs/?52011. It could well be that this fixes the issues discussed in this thread. The patch just arrived a few days ago and as far as I know it hasn’t been inspected by anybody. Still you could give it a try and report back.
Hope this helps, Fred > Am 14.09.2017 um 22:58 schrieb Stefan Bidigaray <[email protected]>: > > I'm still trying to figure out what GNUstep is doing differently from the > tests I'm sending you. As far as I can tell, the results should be identical. > We really do not do anything particularly special. Short of having you step > through the methods step-by-step, checking results along the way, I don't > know what to do. > > I'm going to install FreeBSD in a VM and more thoroughly check this out. It > might be a few days until I get ti all done. > > In the mean time, I fixed the test. It's attached. > > On Thu, Sep 14, 2017 at 4:45 PM, Edwin Ancaer <[email protected]> wrote: > Stefan, > > the result remains correct, but now I had 2 warnings when compiling. I don't > know if that has any meaning though. > > [edwin@ottopedi ~/ICUTest]$ cc test_icu.c `icu-config --ldflags > --ldflags-icuio`-I/usr/local/include > test_icu.c:15:13: warning: implicit declaration of function 'u_strFromUTF8' > is invalid in C99 [-Wimplicit-function-declaration] > pattern = u_strFromUTF8 (buffer, 128, NULL, "yyyyMMdd hh:mm", 14, status); > ^ > test_icu.c:15:11: warning: incompatible integer to pointer conversion > assigning to 'UChar *' (aka 'unsigned short *') from 'int' > [-Wint-conversion] > pattern = u_strFromUTF8 (buffer, 128, NULL, "yyyyMMdd hh:mm", 14, status); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2 warnings generated. > [edwin@ottopedi ~/ICUTest]$ ls -al > total 24 > drwxr-xr-x 2 edwin edwin 512 Sep 14 22:41 . > drwxr-xr-x 38 edwin edwin 3072 Sep 14 22:41 .. > -rwxr-xr-x 1 edwin edwin 7174 Sep 14 22:41 a.out > -rw-r--r-- 1 edwin edwin 1462 Sep 14 22:40 test_icu.c > -rw-r--r-- 1 edwin edwin 1334 Sep 14 22:39 test_icu1.c > [edwin@ottopedi ~/ICUTest]$ > [edwin@ottopedi ~/ICUTest]$ ./a.out > Date Formatted with defaults: 20170914 10:41 p.m. > Date Formatted with defaults: 14 sep. 2017 > Date Formatted with defaults: 14 september 2017 om 22:41:38 CEST > > I you have any ideaes about things that I could try to shed some light on > this.... > > Kind regards, > > Edwin > > > 2017-09-14 22:23 GMT+02:00 Stefan Bidigaray <[email protected]>: > Hmm... There definitely something wrong in GNUstep, then. The question is > what!? Looking at the code, I'm not entirely sure what could be happening, > and why your system is giving different results than mine. You are using ICU > version 58.2, so I'm wondering if some behavior changed between what I have > (version 55.1) and the later ICU releases. > > I modified the previous test to verify that your version of ICU does the same > thing as previous releases. Can you please recheck? Maybe later versions are > be choosing the pattern over the styles. This is the only thing I can think > of, right now. > > Thanks > > On Sep 14, 2017 15:47, "Edwin Ancaer" <[email protected]> wrote: > 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 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
