Sorry, but I think this would be a bad idea. Parsing and formatting functions are always influenced by locale. I don't believe tzcode wants to get into localization issues. That's more the realm of CLDR and ICU. Besides, I don't think tzcode is intended to be a general-purpose date and time library, is it? If so, strf/p is just the tip of the iceberg. -Matt
From: Paul_Koning@dell.com To: christos@zoulas.com Date: Fri, 30 Oct 2015 15:23:44 +0000 CC: tz@iana.org Subject: Re: [tz] include implementations of str{f,p}time{,_l} in tzcode
On Oct 30, 2015, at 9:54 AM, Christos Zoulas <christos@zoulas.com> wrote:
Hello,
I think that it is an omission for those functions not to be included in tzcode. They are tightly bound to the rest of the time code implementation and although standardized, the implementations that the most popular operating systems provide vary in behavior.
Yes, I understand that there are portability considerations (locale for example) that need to be handled, but not including them is taking the easy way out.
If tzcode needs to supply its own versions because the OS supplied versions aren't sufficient or consistent enough, it might make sense to give them different names. Otherwise things get very confusing.
It might also be useful to report those inconsistencies to the OS's that have them, as bugs to be fixed.
paul