Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unix module does not offer access to tzname #5063

Closed
vicuna opened this issue May 28, 2010 · 1 comment
Closed

Unix module does not offer access to tzname #5063

vicuna opened this issue May 28, 2010 · 1 comment

Comments

@vicuna
Copy link

vicuna commented May 28, 2010

Original bug ID: 5063
Reporter: dario
Status: acknowledged (set by @damiendoligez on 2011-06-01T21:01:05Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.2
Category: otherlibs
Tags: patch

Bug description

The "Time Functions" in the Unix module provide comprehensive coverage of the time-related operations available in Libc. There is one conspicuous absence, however: the tzname variable, which provides access to the DST-adjusted abbreviated name of the current timezone. Presently, accessing this value from an Ocaml program requires writing a small C function.

Additional information

The function 'sprint_timestamp' listed below returns a string with the given timestamp pretty-printed in a complete form, ie, including also the abbreviated timezone name adjusted for daylight-savings. It must be written in C, since the Unix module offers no access to the tzname variable.

CAMLprim value sprint_timestamp (value v_time)

    {
    CAMLparam1 (v_time);
    CAMLlocal1 (v_res);

    time_t time = Double_val (v_time);
    struct tm* lt = localtime (&time);
    char res [40];
    snprintf (res, sizeof (res), "%04d-%02d-%02d %02d:%02d:%02d (%s)",
            (lt->tm_year) + 1900, (lt->tm_mon) + 1, lt->tm_mday, lt->tm_hour, lt->tm_min, lt->tm_sec, tzname [lt->tm_isdst]);
    v_res = caml_copy_string (res);

    CAMLreturn (v_res);
    }
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant