Re: Cygwin strptime() is missing "%s" which strftime() has

Re: Cygwin strptime() is missing "%s" which strftime() has

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> But that's just scanning a decimal integer to time_t.

It's not a question of whether I can or can't convert a string into an integer, rather it's a question about portability of code that uses %s for both functions and expects it to work unchanged in the Cygwin environment.  Also, strptime() was designed to be a reversal to strftime() (from the man-pages: the  strptime() function is the converse function to strftime(3)) so both are supposed to "understand" the same basic set of formats.  Because of Cygwin's strptime() missing "%s", the following also does not work even from command line:

$ date +"%s" | strptime "%s"
strptime: cannot make sense of `1500861577' using the given input formats

Thank you,

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Jul 24 02:09, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > But that's just scanning a decimal integer to time_t.
> 
> It's not a question of whether I can or can't convert a string into an
> integer, rather it's a question about portability of code that uses %s

I see your point but... "portability" is kind of the wrong expression
here.  If you have portability in mind, you should *not* use %s at all.
%s is a GNU extension and as such, is not portable by definition.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin strptime() is missing "%s" which strftime() has

[Kaz Kylheku]

On 23.07.2017 19:09, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> But that's just scanning a decimal integer to time_t.
> 
> It's not a question of whether I can or can't convert a string into an
> integer, rather it's a question about portability of code that uses %s
> for both functions and expects it to work unchanged in the Cygwin
> environment.  Also, strptime() was designed to be a reversal to
> strftime() (from the man-pages: the  strptime() function is the
> converse function to strftime(3)) so both are supposed to "understand"
> the same basic set of formats.  Because of Cygwin's strptime() missing
> "%s", the following also does not work even from command line:
> 
> $ date +"%s" | strptime "%s"
> strptime: cannot make sense of `1500861577' using the given input 
> formats

There is no %s in POSIX. It is a GNU C library extension. Thus this is
only a matter of compatibility between Cygwin and GNU/Linux (and 
portability
between those systems).

Linux compatibility *is* an explicit goal of the Cygwin project. If %s 
works
on Linux but not Cygwin, in that moment you're not getting quite that
"Linux feeling" on Windows.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Hans-Bernhard Bröker]

Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:

> rather it's a question about portability of code that
> uses %s for both functions and expects it to work unchanged in the
> Cygwin environment.  

And the answer to that question is: such code _is_not_portable_, and 
therefore that expectation is wrong.

If that code claims to be portable, then its use of %s in either of 
those functions constitutes a _bug_.

In the old days there was a well-known fallacy known by the slogan "all 
the world's a VAX."  Nowadays it appears to have been replaced by an 
equally wide-spread, and equally incorrect belief that all the world is 
Linux.  Well, it's not.  Not even the whole Un*x world is Linux.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Brian Inglis]

On 2017-07-24 15:02, Hans-Bernhard Bröker wrote:
> Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:
> 
>> rather it's a question about portability of code that
>> uses %s for both functions and expects it to work unchanged in the
>> Cygwin environment.  
> 
> And the answer to that question is: such code _is_not_portable_, and therefore
> that expectation is wrong.
> 
> If that code claims to be portable, then its use of %s in either of those
> functions constitutes a _bug_.
> 
> In the old days there was a well-known fallacy known by the slogan "all the
> world's a VAX."  Nowadays it appears to have been replaced by an equally
> wide-spread, and equally incorrect belief that all the world is Linux.  Well,
> it's not.  Not even the whole Un*x world is Linux.

Rather "all the world's a GNU" i.e. glibc, but there's also BSD libc, RTEMS and
Cygwin newlib, and others.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Kaz Kylheku]

On 24.07.2017 15:51, Brian Inglis wrote:
> On 2017-07-24 15:02, Hans-Bernhard Bröker wrote:
>> Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:
>> 
>>> rather it's a question about portability of code that
>>> uses %s for both functions and expects it to work unchanged in the
>>> Cygwin environment.
>> 
>> And the answer to that question is: such code _is_not_portable_, and 
>> therefore
>> that expectation is wrong.
>> 
>> If that code claims to be portable, then its use of %s in either of 
>> those
>> functions constitutes a _bug_.
>> 
>> In the old days there was a well-known fallacy known by the slogan 
>> "all the
>> world's a VAX."  Nowadays it appears to have been replaced by an 
>> equally
>> wide-spread, and equally incorrect belief that all the world is Linux. 
>>  Well,
>> it's not.  Not even the whole Un*x world is Linux.
> 
> Rather "all the world's a GNU" i.e. glibc, but there's also BSD libc, 
> RTEMS and
> Cygwin newlib, and others.

Since the utilities depend on the C library functionality for strptime 
and
strftime, even having GNU utilities won't help.

There doesn't appear any nice way in POSIX shell scripting to have 
access to
the seconds since the Epoch.

If you have GNU Awk, it has some time functions like mktime, which don't 
rely
on any C library extensions.

     $ gawk 'BEGIN { print mktime("2017 07 22 12 31 55") }'
     1500751915
     $ gawk 'BEGIN { print systime() }'
     1500938050

If you can install GNU Awk on a system, chances are you can get some 
real
programming language, too, though. GNU Awk may be a little more common 
in
that if, for your given OS, a bundle of freeware exists, chances are 
good
that GNU Awk is part of its core.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Brian Inglis]

On 2017-07-24 17:18, Kaz Kylheku wrote:
> On 24.07.2017 15:51, Brian Inglis wrote:
>> On 2017-07-24 15:02, Hans-Bernhard Bröker wrote:
>>> Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:
>>>
>>>> rather it's a question about portability of code that
>>>> uses %s for both functions and expects it to work unchanged in the
>>>> Cygwin environment.
>>>
>>> And the answer to that question is: such code _is_not_portable_, and therefore
>>> that expectation is wrong.
>>>
>>> If that code claims to be portable, then its use of %s in either of those
>>> functions constitutes a _bug_.
>>>
>>> In the old days there was a well-known fallacy known by the slogan "all the
>>> world's a VAX."  Nowadays it appears to have been replaced by an equally
>>> wide-spread, and equally incorrect belief that all the world is Linux.  Well,
>>> it's not.  Not even the whole Un*x world is Linux.
>>
>> Rather "all the world's a GNU" i.e. glibc, but there's also BSD libc, RTEMS and
>> Cygwin newlib, and others.
> 
> Since the utilities depend on the C library functionality for strptime and
> strftime, even having GNU utilities won't help.
> 
> There doesn't appear any nice way in POSIX shell scripting to have access to
> the seconds since the Epoch.
> 
> If you have GNU Awk, it has some time functions like mktime, which don't rely
> on any C library extensions.

If you have GNU gawk you probably also have GNU coreutils date, which supports
+%s for output and -d@nnnnnnnnnn for input, whether or not the system strftime
and strptime support %s.

GNU coreutils date with shell arithmetic is adequate to support shell script
conversions between time scales with different epochs e.g. Julian Day, Modified
Julian Day, NTP, Unix, GPS, and calculations using those values.

Awk, JS, or some other language supporting FP is required for subsecond or
fractional day accuracy with convenient output.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Brian Inglis]

On 2017-07-25 10:47, Brian Inglis wrote:
> On 2017-07-24 17:18, Kaz Kylheku wrote:
>> On 24.07.2017 15:51, Brian Inglis wrote:
>>> On 2017-07-24 15:02, Hans-Bernhard Bröker wrote:
>>>> Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:
>>>>
>>>>> rather it's a question about portability of code that
>>>>> uses %s for both functions and expects it to work unchanged in the
>>>>> Cygwin environment.
>>>>
>>>> And the answer to that question is: such code _is_not_portable_, and therefore
>>>> that expectation is wrong.
>>>>
>>>> If that code claims to be portable, then its use of %s in either of those
>>>> functions constitutes a _bug_.
>>>>
>>>> In the old days there was a well-known fallacy known by the slogan "all the
>>>> world's a VAX."  Nowadays it appears to have been replaced by an equally
>>>> wide-spread, and equally incorrect belief that all the world is Linux.  Well,
>>>> it's not.  Not even the whole Un*x world is Linux.
>>>
>>> Rather "all the world's a GNU" i.e. glibc, but there's also BSD libc, RTEMS and
>>> Cygwin newlib, and others.
>>
>> Since the utilities depend on the C library functionality for strptime and
>> strftime, even having GNU utilities won't help.
>>
>> There doesn't appear any nice way in POSIX shell scripting to have access to
>> the seconds since the Epoch.
>>
>> If you have GNU Awk, it has some time functions like mktime, which don't rely
>> on any C library extensions.
> 
> If you have GNU gawk you probably also have GNU coreutils date, which supports
> +%s for output and -d@nnnnnnnnnn for input, whether or not the system strftime
> and strptime support %s.
> 
> GNU coreutils date with shell arithmetic is adequate to support shell script
> conversions between time scales with different epochs e.g. Julian Day, Modified
> Julian Day, NTP, Unix, GPS, and calculations using those values.
> 
> Awk, JS, or some other language supporting FP is required for subsecond or
> fractional day accuracy with convenient output.

Patch in latest test release provides %s support for strptime(3) used by
strptime(1).
Another strptime(3) patch was just submitted to fix %F handling.
More newlib time patches coming to fix handling years around INT_MAX and high
values of time_t.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> then its use of %s in either of those functions constitutes a _bug_

Oh really?  Is that why "%s" was added to Cygwin's strftime() lately?

Thanks again for your input.

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1465 bytes --]

On 07/24/2017 04:28 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> then its use of %s in either of those functions constitutes a _bug_
> 
> Oh really?  Is that why "%s" was added to Cygwin's strftime() lately?

Your mailer is breaking up threads, which is making it very annoying to
follow where your replies are landing.

strftime() has been formatting %s since Oct 2015 (if you can call that
"lately").  In fact, you made me check git history: it was not me that
added it (like I thought, so I must have added it in gnulib instead);
but Brian - in fact, the same Brian who is now working on adding %s to
strptime().

The point remains: if you want your program to be portable, you should
not use %s.  But if your program is okay with demanding a GNU/Linux
environment rather than sticking to portable code, then Cygwin still
tries to cater to that by providing as many GNU/Linux extensions as
possible, and pointing out where we fall short is appreciated.  But
still, someone has to code it, this is a volunteer effort, and we tend
to scratch our own itches.  The fact that strptime() lagged strftime()
by nearly 2 years in adding %s support is par for the course.  It's not
worth complaining about, and if you want faster action, then submit
patches yourself instead of asking others to do it for you.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Cygwin strptime() is missing "%s" which strftime() has

[Brian Inglis]

On 2017-07-24 15:48, Eric Blake wrote:
> On 07/24/2017 04:28 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>>> then its use of %s in either of those functions constitutes a _bug_
>>
>> Oh really?  Is that why "%s" was added to Cygwin's strftime() lately?
> 
> Your mailer is breaking up threads, which is making it very annoying to
> follow where your replies are landing.
> 
> strftime() has been formatting %s since Oct 2015 (if you can call that
> "lately").  In fact, you made me check git history: it was not me that
> added it (like I thought, so I must have added it in gnulib instead);
> but Brian - in fact, the same Brian who is now working on adding %s to
> strptime().
> 
> The point remains: if you want your program to be portable, you should
> not use %s.  But if your program is okay with demanding a GNU/Linux
> environment rather than sticking to portable code, then Cygwin still
> tries to cater to that by providing as many GNU/Linux extensions as
> possible, and pointing out where we fall short is appreciated.  But
> still, someone has to code it, this is a volunteer effort, and we tend
> to scratch our own itches.  The fact that strptime() lagged strftime()
> by nearly 2 years in adding %s support is par for the course.  It's not
> worth complaining about, and if you want faster action, then submit
> patches yourself instead of asking others to do it for you.

My itch is that it doesn't work in dateutils strptime(1), so the hope is that if
%s (also %F) works in newlib libc strptime(3), that will get it working in
dateutils strptime(1), as it does in coreutils date(1), or I'll have to do some
more scratching.

Of course, C code could just convert the seconds strings to some BIG_INT, put it
in a time_t, and use localtime(3) or gmtime(3) to get a struct tm for use in
strftime(3). Shell scripts could use coreutils date(1) instead of dateutils
strptime(1) to convert time_t using %s (and more). It would be great if all the
time utilities and functions could support a consistent set (GNU) of time
conversion specifications.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> Demand.  I patches strftime to add %s because Coreutils wanted it.  But
> coreutils doesn't use strptime, so I had no reason to add it.

Well, I was bringing up a point of API inconsistency, hoping that it'd serve as an
implicit request for an improvement so that strptime() gets its "%s"...

Maybe coreutils did not need "%s" for strptime, but dateutils certainly do, as:

> date +"%s" | strptime "%s"

does not work on Cygwin.  That looks odd.

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> > > But that's just scanning a decimal integer to time_t.
> > 
> > It's not a question of whether I can or can't convert a string into an
> > integer, rather it's a question about portability of code that uses %s

> I see your point but... "portability" is kind of the wrong expression
> here.  If you have portability in mind, you should *not* use %s at all.

The point is, if I can use "%s" with strftime() on Cygwin, then I should be able to use "%s" with strptime(),
but currently there's a disconcert with that.  Indeed, "%s" is a GNU extension yet it has been on Linux for years,
so why not here but only 50%?

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 978 bytes --]

On 07/24/2017 08:24 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>>>> But that's just scanning a decimal integer to time_t.
>>>
>>> It's not a question of whether I can or can't convert a string into an
>>> integer, rather it's a question about portability of code that uses %s
> 
>> I see your point but... "portability" is kind of the wrong expression
>> here.  If you have portability in mind, you should *not* use %s at all.
> 
> The point is, if I can use "%s" with strftime() on Cygwin, then I should be able to use "%s" with strptime(),
> but currently there's a disconcert with that.  Indeed, "%s" is a GNU extension yet it has been on Linux for years,
> so why not here but only 50%?

Demand.  I patches strftime to add %s because Coreutils wanted it.  But
coreutils doesn't use strptime, so I had no reason to add it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Cygwin strptime() is missing "%s" which strftime() has

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Hello,

It looks like Cygwin implementation of strptime(3) cannot understand the "%s" format (seconds since Jan 1, 1970 UTC), which strftime() can.

When I test the same code of Linux, it appears to work correctly.

Cygwin:
$ gcc -Wall -o timetest timetest.c
$ ./timetest
1500755837 -> 1500755837
Cannot convert string

Linux:

$ gcc -Wall -o timetest timetest.c
$ ./timetest
1500755887 -> 1500755887
1500755887 -> 1500755887, unconverted: ""

Anton Lavrentiev
Contractor NIH/NLM/NCBI

$ cat timetest.c
#define _XOPEN_SOURCE
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

int main()
{
    time_t now = time(0);
    struct tm tm = *localtime(&now);
    char str[80], *s;
    size_t n = strftime(str, sizeof(str), "%s", &tm);
    if (!n) {
        printf("Cannot convert time");
        return 1;
    }
    assert(n == strlen(str));
    printf("%lu -> %s\n", (unsigned long) now, str);
    memset(&tm, 0, sizeof(tm));
    if (!(s = strptime(str, "%s", &tm))) {
        printf("Cannot convert string");
        return 1;
    }
    now = mktime(&tm);
    printf("%s -> %lu, unconverted: \"%s\"\n", str, (unsigned long) now, s);
    return 0;    
}


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin strptime() is missing "%s" which strftime() has

[Kaz Kylheku]

On 22.07.2017 13:48, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hello,
> 
> It looks like Cygwin implementation of strptime(3) cannot understand
> the "%s" format (seconds since Jan 1, 1970 UTC), which strftime() can.

But that's just scanning a decimal integer to time_t.

Where implemented, how does that deal with overflows and such compared 
to strtoul?


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple