Re: NSDateFormatter SetDateStyle / setTimeStyle not working

[Stefan Bidigaray]

FYI, I finally pushed the fix. Took me long enough, but it eventually got done.

On Tue, Sep 19, 2017 at 3:58 AM, Edwin Ancaer <eancaer@gmail.com> wrote:

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 <fredkiefer@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 <stefanbidi@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 <eancaer@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 <stefanbidi@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" <eancaer@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 <stefanbidi@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 <stefanbidi@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" <eancaer@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 <stefanbidi@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" <eancaer@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