I managed to apply the first patch, setting the the initial dateFormat to nil, and that did solve my problem. I had to do it manually, maybe it did not work with the patch instruction, because I have version 1.24.8 of gnustep-base, and the patch was made for 1.24.9?
The other patch failed at compilation, because I have no variable named 'pat' in my version. of NSDateFormatter.m. After make check, I have no more errors in NSDate / NSDateFormatter.m. Can't help to feel a little proud of myself, the old dog can still learn some new tricks.... 2017-09-15 8:44 GMT+02:00 Fred Kiefer <fredkie...@gmx.de>: > 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 <stefanb...@gmail.com>: > > > > 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 <eanc...@gmail.com> 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 <stefanb...@gmail.com>: > > 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" <eanc...@gmail.com> 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 <stefanb...@gmail.com>: > > 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 <stefanb...@gmail.com> > 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" <eanc...@gmail.com> 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 <stefanb...@gmail.com>: > > 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" <eanc...@gmail.com> 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 > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > > > > > > _______________________________________________ > > Discuss-gnustep mailing list > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > > > > > > > > > > _______________________________________________ > > Discuss-gnustep mailing list > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > _______________________________________________ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >
_______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
