Open reith opened 10 years ago
Making jcal local-aware is something that I had in mind at first. However, after giving it a thought I discarded the idea altogether since Jalali date representation is unique to fa_IR locale and anything outside this scope would probably use the Gregorian date representation instead. Now, making jcal locale-aware requires a certain amount of work to be done and there are other issues at hand. That aside, there is the problem of breaking backward compatibility. However, I'm willing to break that backward compatibility to make libjalali more POSIX compatible API wise if I find the proper amount of time to do it. It is also worth noting that libjalali is NOT part of POSIX standard and possibly never will be. There is no point in maintaining something that nobody actually uses. Farvardin is spelled "Farvardin" in any locale other than fa_IR and nothing other that fa_IR locale uses Jalali date representation. It is important to understand why different locales exist and what makes them important to consider. In that sense, libjalali is not a perfect candidate to be locale-aware.
Currently Jcal is agnostic about locale settings and provides some custom formatting directives for representation stuff. Setting locale settings for representation is an standard way used for invoking
date
or during library function calls. I see no reason whyjdate
-jstrftime
actually- should be different thandate
(strftime
) in this matter.Additionally it's not easy to maintain custom formatting directives for locale-specific representation, as it already has override some in Linux. Probably there is some issues in less used platforms too. This approach is not very flexible too, since free directive characters are limited.
So why not just make
jstrftime
locale aware and then provide some switch, e.g. --in-farsi to set locale forjstrftime
call? Also another switch --with-custom-directives could set locale and translate currently supported custom directive to POSIX directive beforejstrftime
call.I see this would break softwares depended on current approach, but it simplifies making softwares that used to work in standard POSIX ecosystem, on top of libjalali. Also not using custom special characters with new meaning would be easy for people with fragile memory, like me.
Share your general and implementation ideas please.