[bug #29208] NSCalendarDate's format does not support the %k conversion specifier
Update of bug #29208 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: I applied that patch ... thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29208 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29208] NSCalendarDate's format does not support the %k conversion specifier
Follow-up Comment #2, bug #29208 (project gnustep): Thanks. Here is my attemt; I'd appreciate a thorough review. The leading space is important for sorting/alignment -- I see that %e omits it (contrary to what the documentation says); probably to match Cocoa behavior? Tested with the attached program (test2.m) as follows: $ LC_ALL=C ./obj/test2 %H:%M:%S 04:03:30 (nil) 13:19:28 $ LC_ALL=en_US.UTF-8 ./obj/test2 %r 04:03:30 AM (nil) 01:19:40 PM $ ./obj/test2 %k,%M,%S 4,03,30 1,02,03 13,19,51 $ defaults write NSGlobalDomain GSMacOSXCompatible YES $ LC_ALL=C ./obj/test2 %H:%M:%S 04:03:30 (nil) 13:20:20 $ LC_ALL=en_US.UTF-8 ./obj/test2 %r 04:03:30 AM (nil) 01:20:31 PM $ ./obj/test2 2010-03-13 13:20:45.223 test2[6349] Invalid NSCalendar date, specifier k not recognized in format %k,%M,%S %k,%M,%S %k,03,30 (nil) %k,20,45 P.S. I'm not sure if my changes until now are already legally significant, but either way (whether the patch is rejected or not), I'd be happy to assign past and future changes to the FSF at any time. (file #19929, file #19930) ___ Additional Item Attachment: File name: k.patchSize:3 KB File name: test2.mSize:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?29208 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29208] NSCalendarDate's format does not support the %k conversion specifier
URL: http://savannah.gnu.org/bugs/?29208 Summary: NSCalendarDate's format does not support the %k conversion specifier Project: GNUstep Submitted by: yavor Submitted on: Fri 12 Mar 2010 03:41:18 PM EET Category: Base/Foundation Severity: 3 - Normal Item Group: Change Request Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: While preparing the upload of SimpleAgenda/0.40 for Debian I discovered something unpleasant -- the time in the app icon is displayed as '%k,minutes,seconds' when run under Bulgarian locale. This is because our locale definition is '%k,%M,%S'. (The %k specifier is a GNU extension according to the glibc manual, which makes its use perfectly valid in a glibc locale.) Unfortunately NSCalendarDate (as documented) does not understand it. I checked the Cocoa documentation, and there's no %k there too (not surprising). Would you accept a patch implementing support for the %k specifier? I hope that Apple not implementing it won't be an obstacle... AFAICS from the online documentation, `strftime' in FreeBSD, OpenSolaris and even Mac OS X support it, so it's not something strictly GNU-specific. The attached test program demonstrates the current ugliness: $ LC_ALL=C ./obj/test %H:%M:%S 15:37:17 $ LC_ALL=en_US.UTF-8 ./obj/test %r 03:38:37 PM $ ./obj/test %k,%M,%S %k,38,48 ___ File Attachments: --- Date: Fri 12 Mar 2010 03:41:18 PM EET Name: test.m Size: 401B By: yavor http://savannah.gnu.org/bugs/download.php?file_id=19920 ___ Reply to this item at: http://savannah.gnu.org/bugs/?29208 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29208] NSCalendarDate's format does not support the %k conversion specifier
Follow-up Comment #1, bug #29208 (project gnustep): I'd be very happy to have a patch to support this. Yes please. It would be ideal if you could bracket the behavior with: if (NO == GSPrivateDefaultsFlag(GSMacOSXCompatible)) That way, if someone sets the GSMacOSXCompatible user default to YES, they would get OSX compatible behavior. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29208 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep