include implementations of str{f,p}time{,_l} in tzcode
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. Best, christos
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
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
Matt Johnson <mj1856@hotmail.com> writes:
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.
I'm not sure what exactly the library sections tzcode are meant to be, these days. My impression is that it was originally a drop-in replacement for libc functions on Unix systems from before these features standardized or were widely implemented. That would explain why it _does_ ship with a version of strftime.
participants (4)
-
christos＠zoulas.com -
Matt Johnson -
Paul_Koning＠dell.com -
Random832