ashkang / jcal Goto Github PK

libjalali uses two different conventions for naming months and weekdays simultaneously. In jtime.c I see month names as in Iranian calendar but weekdays named as Gregorian or Iranian when specified by fa prefix or suffix.

Operations dealing with implicit representation format, e.g. jasctime() or jstrftime's '%c' directive indicating preferred format, elect Gregorian weekday names but Iranian month names. This is counter-intuitive. I doubt it be even possible to get Gregorian month name by jstrftime with custom directives, so weekdays probably should be named similarly.

Hi, I was wondering how can I include libjalali in my Makefile.am and/or configure.ac file.

Right now I am doing something like:

gahshomar_LDADD = $(GAHSHOMAR_LIBS) /usr/lib/libjalali.la

Is there a better way to do this?

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 why jdate -jstrftime actually- should be different than date (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 for jstrftime call? Also another switch --with-custom-directives could set locale and translate currently supported custom directive to POSIX directive before jstrftime 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.

At the moment, there are no proper documentations on how to use pyjalali and there are no proper mechanisms to install pyjalali system-wide using automake directives in Makefile.am. There should be a test kit and an example according to project policy, that should demonstrate basic features of the library. It should be placed alongside C code examples in test_kit directory. Perhaps, it would be better if we rename test_kit/jtime directory to something more meaningful, something like "examples".

Seems that there is an excess space in 3 month view or year view in a specific condition. Where current day is Friday and all days of that row are two digits.

For example on 1392/08/24, excess space is before Azar/16

http://i.imgur.com/fwB0VFY.png

strncpy() behaves differently across platforms when it comes to null termination of destination string. On BSDs, null termination of destination string must be done explicitly. Things are in correct order on standard elibc and glibc implementations. It causes incorrect format parsing on BSDs (_BSD_SOURCE). strlcpy() is also non-existent on platforms other than BSDs.

It's not standard for jmktime or jstrftime to depend on jtm.tm_gmtoff.
Instead they should use local timezone values. At-least for strftime it said in POSIX.1-2008:

Local timezone information is used as though strftime() called tzset().

Current approach makes timezone unaware transforms hard.

This is a test showing incompatibilities with Linux glibc:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <jtime.h>
#include <jalali.h>

char b[100];
#define print_ts_z(frm, tm, f) {f(b, 100, frm, &tm); puts(b);}

void print_tm(const struct tm* tm) {
    printf("year: %d\nmonth: %d\nday: %d\nhour: %d\nminute: %d\nsecond: %d\n" \
                 "yday: %d\nwday: %d\nisdst: %d\ngmtoff: %ld\nzone: %s\n", tm->tm_year,
                 tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec, 
                 tm->tm_yday, tm->tm_wday, tm->tm_isdst, tm->tm_gmtoff, tm->tm_zone); 
}

int jmktime_test() {
    struct tm tm;
    time_t ts;

    time(&ts);
    localtime_r(&ts, &tm);
    tm.tm_gmtoff = 0;
    tm.tm_zone = NULL;
    printf("mktime on zeroed tz-> %ld\n", mktime(&tm));
    print_tm(&tm);

    puts("******");

    struct jtm jtm;
    jlocaltime_r(&ts, &jtm);
    jtm.tm_gmtoff = 0;
    jtm.tm_zone = NULL;
    printf("jmktime on zeroed tz-> %ld\n", jmktime(&jtm));
    print_tm((const struct tm*)&jtm);

    return 0;
}

int jstrftime_test() {
    struct tm tm;
    time_t ts;

    time(&ts);
    localtime_r(&ts, &tm);
    print_ts_z("strftime '%%s' on localtime output: %s", tm, strftime);
    tm.tm_gmtoff = 0;
    tm.tm_zone = NULL;
    print_ts_z("strftime '%%s' on zeroed zone: %s", tm, strftime);

    struct jtm jtm;
    jlocaltime_r(&ts, &jtm);
    print_ts_z("jstrftime '%%s' on localtime output: %s", jtm, jstrftime);
    jtm.tm_gmtoff = 0;
    tm.tm_zone = NULL;
    print_ts_z("jstrftime '%%s' on zeroed zone: %s", jtm, jstrftime);
    return 0;
}

int main() {
    puts("****  jstrftime() test  ****");
    jstrftime_test();
    puts("\n****  jmktime() test  ****");
    jmktime_test();
    return 0;
}

The output I've got on a machine with non-UTC localtime:

****  jstrftime() test  ****
strftime '%s' on localtime output: 1385304535
strftime '%s' on zeroed zone: 1385304535
jstrftime '%s' on localtime output: 1385304535
jstrftime '%s' on zeroed zone: 1385317135

****  jmktime() test  ****
mktime on zeroed tz-> 1385304535
year: 113
month: 10
day: 24
hour: 18
minute: 18
second: 55
yday: 327
wday: 0
isdst: 0
gmtoff: 12600
zone: IRST
******
jmktime on zeroed tz-> 1385317135
year: 1392
month: 8
day: 3
hour: 18
minute: 18
second: 55
yday: 248
wday: 1
isdst: 0
gmtoff: 0
zone: (null)

1278/10/11 solar equivalent 1900/1/1 AD (Of course in tm struct, months start from 0 )
I compiled the following code in two architectures i386 and amd64:
////////////////////////////////////////////////////////////////////////////////////////////

   #include <stdio.h>
   #include <stdlib.h>
   #include <time.h>
   #include <jalali.h>
   #include <jtime.h>

   int
   main(int argc, char ** argv)
   {
       struct tm tm = {0};
       struct jtm jtm = {0};
       time_t t;

       jtm.tm_year = 1278;
       jtm.tm_mon = 10;
       jtm.tm_mday = 11;

       t = jmktime(&jtm);
       localtime_r(&t, &tm);
       printf("%d/%d/%d \n", tm.tm_year+1900, tm.tm_mon, tm.tm_mday);
       exit(EXIT_SUCCESS);
   }

/////////////////////////////////////////////////////////////////////////////////////////
Result in amd64:
1900/0/30
Result in i386:
2036/2/8
It's related to problem 2038 at :
http://en.wikipedia.org/wiki/Year_2038_problem
Solution:
At first we need to define two typedef:
//////////////////////////////////////

#ifdef i386
     typedef unsigned int time_t;
#elif defined(x86_64) || defined(_M_AMD64) || defined (_M_X64) 
     typedef time_t time_t;
#endif

////////////////////////////
Then anywhere we need variable from time_t , we can do such as :
////////////////////

 time_t   t;

///////////////////////////////
In Total:
jcal project has problem for programmer in i386.

Provide a tag and first version

    struct tm tm;
    struct jtm jtm;
    time_t ts = 1367157243;

    localtime_r(&ts, &tm);
    jlocaltime_r(&ts, &jtm);
    jalali_update(&jtm);

    assert(jtm.tm_isdst == tm.tm_isdst); 
    assert(jtm.tm_gmtoff == tm.tm_gmtoff);

jalali_update resets zone information to IRST (which is same as current timezone on my machine) but for specified timestamp DST is in effect (first half of year)

Hi.
Do you think It is possible to add holidays to jcal? Nothing complicated, just red other holidays except Fridays .
I think I can help but I dont know if is it possible, and where to start.
Please let me know your thoughts around it.
Thanks

Possibly as a switch. Something like -S.
Bahman 1392
January/February 2014
Sh Ye Do Se Ch Pa Jo
1/21 2/22 3/23 4/24
5/25 6/26 7/27 8/28 9/29 10/30 11/31
12/1 13/2 14/3 15/4 16/5 17/6 18/7
19/8 20/9 21/10 22/11 23/12 24/13 25/14
26/15 27/16 28/17 29/18 30/19

This is to inform all visitors that unfortunately the owner of this repository passed away in October 2017. Ashkan died in a sudden unpredicted incident. Therefore, transfer of this repository to someone else was impossible.

jcal is not further developed here. I recommend new issues to be submitted to this forked version developed & maintained actively by Forud.

دوستان سلام. متاسفانه اشکان در اکتبر سال ۲۰۱۷ فوت شدند و این رپوزیتوری دیگر توسعه داده نمی‌شود. برای گزارش مشکلات جدید و توسعه این نرم افزار، بنده نسخه فورک شده توسط فرود را توصیه می‌کنم. لینک‌ها را هم بالا در نسخه انگلیسی این پست گذاشتم.