Re: NSDateFormatter SetDateStyle / setTimeStyle not working

[Fred Kiefer]

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