GNU awk mktime() UTC

[Janis Papanagnou]

I am using GNU awk's time functions to process UTC based time stamps.

According to the manual:
Function systime() is already defined based on UTC epoch.
Function strftime() has an optional UTC flag that can be specified.
Function mktime() suports a DST flag but no UTC specifier, it assumes
the timestamp to be provided in local time.

It seems that I cannot specify any other time location (not even UTC
standard time) but only local time when using mktime(). It also seems
that the GNU awk time functions (systime() and mktime()) are defined
inconsistently WRT UTC/local time.

I use (in Unix shell) this workaround to make it do what I want

TZ=UTC awk '...
time_in_sec = mktime(date_spec_str)
...'

but it looks wrong to define a globally effective environment variable
for the whole awk program.

Is there a better way, or something obvious I am missing?

Wouldn't it make sense if gawk would support UTC in mktime() with an
optional argument: mktime(datespec [,utc-flag]) ?

Janis

[Ed Morton]

Indeed. If ONLY awk supported a mktime()-like function that took a timezone
argument (hint:
https://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html).

Ed.

[Hermann Peifer]

On 17/02/2017 15:06, Janis Papanagnou wrote:
>
> I use (in Unix shell) this workaround to make it do what I want
>
> TZ=UTC awk '...
> time_in_sec = mktime(date_spec_str)
> ...'
>
> but it looks wrong to define a globally effective environment variable
> for the whole awk program.
>
> Is there a better way, or something obvious I am missing?
>

Setting ENVIRON["TZ"] might help, but only when using gawk/master from git.

Hermann

$ gawk 'BEGIN{ print mktime("2017 1 1 0 0 0") }'
1483225200

# GNU Awk 4.1.4
$ /opt/local/bin/gawk 'BEGIN{ ENVIRON["TZ"] = "UTC"; print mktime("2017
1 1 0 0 0") }'
1483225200

# gawk/master from git
$ gawk 'BEGIN{ ENVIRON["TZ"] = "UTC"; print mktime("2017 1 1 0 0 0") }'
1483228800

[Janis Papanagnou]

On 17.02.2017 23:28, Hermann Peifer wrote:
> On 17/02/2017 15:06, Janis Papanagnou wrote:
>>
>> I use (in Unix shell) this workaround to make it do what I want
>>
>> TZ=UTC awk '...
>> time_in_sec = mktime(date_spec_str)
>> ...'
>>
>> but it looks wrong to define a globally effective environment variable
>> for the whole awk program.
>>
>> Is there a better way, or something obvious I am missing?
>>
>
> Setting ENVIRON["TZ"] might help, but only when using gawk/master from git.

A new feature obviously (I had tried that with my GNU Awk 4.1.2, where it
could be set but was ineffective). So in future releases we can work around
the issue from within GNU awk. Thanks for that information.

Janis

[Hermann Peifer]

On 17/02/2017 23:52, Janis Papanagnou wrote:
> On 17.02.2017 23:28, Hermann Peifer wrote:
>> On 17/02/2017 15:06, Janis Papanagnou wrote:
>>>
>>> I use (in Unix shell) this workaround to make it do what I want
>>>
>>> TZ=UTC awk '...
>>> time_in_sec = mktime(date_spec_str)
>>> ...'
>>>
>>> but it looks wrong to define a globally effective environment variable
>>> for the whole awk program.
>>>
>>> Is there a better way, or something obvious I am missing?
>>>
>>
>> Setting ENVIRON["TZ"] might help, but only when using gawk/master from git.
>
> A new feature obviously (I had tried that with my GNU Awk 4.1.2, where it
> could be set but was ineffective). So in future releases we can work around
> the issue from within GNU awk. Thanks for that information.
>

Indeed: this feature is #1 on the NEWS list for version 4.2.0, see
http://git.savannah.gnu.org/cgit/gawk.git/tree/NEWS

Hermann

[Kenny McCormack]

In article <o8701e$msb$1...@news-1.m-online.net>,

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>I am using GNU awk's time functions to process UTC based time stamps.
>
>According to the manual:
>Function systime() is already defined based on UTC epoch.
>Function strftime() has an optional UTC flag that can be specified.
>Function mktime() suports a DST flag but no UTC specifier, it assumes
>the timestamp to be provided in local time.
>
>It seems that I cannot specify any other time location (not even UTC
>standard time) but only local time when using mktime().

I've written an extension library for this. You can find it at the usual
URL (at the usual PORT) - the filename is "mktime_ex.zip".

Here are the opening comments in the .c file:

* mktime_ex.c - Extended version of GAWK's mktime() function.
* If called with 1 arg, do exactly as mktime().
* If 2 args, and second arg is "", do timegm() instead of mktime().
* If 2 args, and second arg is not "", set TZ=arg2, then call mktime().

Sample usage: x = mktime_ex("2017 2 17 12 0 0","America/Los_Angeles")

P.S. It would also be nice to have a version of strftime() that allowed a
timezone argument - for if you want to display the time in some other
timezone. Right now, your only choices are local time and UTC.

>It also seems that the GNU awk time functions (systime() and mktime()) are
>defined inconsistently WRT UTC/local time.

I'm not sure what you mean here. Could you clarify?
(Note: I'm not saying you're wrong; I just don't know what you are
referring to)

--
He must be a Muslim. He's got three wives and he doesn't drink.

[Janis Papanagnou]

On 18.02.2017 18:17, Kenny McCormack wrote:
>> [...]

>
> I've written an extension library for this. You can find it at the usual
> URL (at the usual PORT) - the filename is "mktime_ex.zip".

I'll have a look at it. (Provided that I'll find the "usual" URL/port.)
Thanks!

>
>> It also seems that the GNU awk time functions (systime() and mktime()) are
>> defined inconsistently WRT UTC/local time.
>
> I'm not sure what you mean here. Could you clarify?

I just meant that mktime() returns seconds given _local time_ (DST optional),
while systime() returns seconds given _UTC_. The functon call interface does
not suport UTC in case of mktime() (and no "local time seconds" - whether
that makes sense or not - with systime(). This is one inconsistency; seconds
are Epoch seconds but there's no possibilities to specify the arguments to
be interpreted as UTC. Generally I think that UTC should always be supported
in one way or another. And I cannot understand why it's not supported given
that there is a UTC flag in gawk's strftime(). The set of time functions is
defined inconsistently from user's (or at least from my) perspective.

(I also try to avoid side effects in functions, like my shell workaround with
TZ=UTC, or by explicitly setting ENVIRON["TC"]="UTC"[*] with the current gawk
respository version. That should be directly controllable using a function
parameter, not by a global variable. Specifically if it's a clean extension
[with an additional, optional function argument] that does not even break any
existing code.)

The whole point is that there should be a way to specify _what time_ it is
that is presented as argument, given the insight that there is not only "one
time" existing. The internal representation should be consistent (say, Unix
Epoch seconds UTC) and the user interface should allow specifying any "real"
time to convert from/to internal mtime. UTC, as the standard, is outstanding
here, but other TZs (as supported with your extension) is valuable as well.

Janis

[*] We should be aware that using ENVIRON["TZ"] to adjust function behaviour
is bulky, and conceptually reflects very old Fortran programming paradigms,
i.e. technology used in the 1960's.

[Kenny McCormack]

In article <o8a8nl$msd$1...@news-1.m-online.net>,

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>On 18.02.2017 18:17, Kenny McCormack wrote:
>>> [...]
>>
>> I've written an extension library for this. You can find it at the usual
>> URL (at the usual PORT) - the filename is "mktime_ex.zip".
>
>I'll have a look at it. (Provided that I'll find the "usual" URL/port.)
>Thanks!

Good to hear. The URL/PORT were published earlier in various other threads
in this newsgroup. I just don't like to write any more often than I have
to, because of the 'bots.

>>> It also seems that the GNU awk time functions (systime() and mktime()) are
>>> defined inconsistently WRT UTC/local time.
>>
>> I'm not sure what you mean here. Could you clarify?
>
>I just meant that mktime() returns seconds given _local time_ (DST optional),
>while systime() returns seconds given _UTC_.

The thing you have to understand is that both of these functions are just
thin wrappers (almost pass-throughs) to various underlying C (POSIX) library
time functions. So, basically, they are the way they are because that's
the way the underlying library functions are. I.e., "Don't blame the GAWK
developers".

For example, the GAWK "mktime" function is a thin wrapper around the C
library function of the same name. Now, it turns out that the C library
also has a function called "timegm" - that is identical to "mktime" except
that the input data is assumed to be in UTC rather than in local time
(i.e., local time as indicated by the setting of the TZ env var - or the
equivalent, since TZ is sort of obsolete/deprecated in today's Linux/Unix
(I.e., POSIX) world).

One of the things my extension library does is give you direct access to
"timegm", and this should solve your underlying issue.

That all said, I must emphasize that there is only one "Epoch time" number.
It is (modulo the issue of so-called "leap seconds") the number of seconds
elapsed since 4 PM, December 31st, 1969 (Los Angeles time). That's what
systime() returns. It is also what mktime() returns - based on
interpreting the string you pass relative to your local timezone. To
re-iterate, if GAWK gave you native access to timegm(), then you could pass
in a string that would be interpreted relative to UTC rather than one
relative to your local timezone. And if GAWK gave you a meaningful way to
change the value of TZ on the fly, you could get "Epoch time" from a string
expressed in any timezone that you wanted.

>The function call interface does not support UTC in case of mktime() (and

>no "local time seconds" - whether that makes sense or not - with
>systime(). This is one inconsistency; seconds are Epoch seconds but
>there's no possibilities to specify the arguments to be interpreted as
>UTC. Generally I think that UTC should always be supported in one way or
>another. And I cannot understand why it's not supported given that there
>is a UTC flag in gawk's strftime(). The set of time functions is defined
>inconsistently from user's (or at least from my) perspective.

As I've tried to make clear above, it just hasn't come up until now.
As of the current writing, GAWK does not give you access to "timegm"; it
only gives you access to "mktime". Nor does it give you any meaningful way
to change the environment (i.e., the content of the running process's
environment variables) once your script is running. My various extension
libs address all of these problems (and more). The so-called "master"
branch of GAWK (which will someday be released as GAWK 4.2) addresses the
later issue (though not as well - in the context of this particular issue -
as mine does).

>(I also try to avoid side effects in functions, like my shell workaround with
>TZ=UTC, or by explicitly setting ENVIRON["TC"]="UTC"[*] with the current gawk
>respository version. That should be directly controllable using a function
>parameter, not by a global variable. Specifically if it's a clean extension
>[with an additional, optional function argument] that does not even break any
>existing code.)

I agree totally with this paragraph.

>The whole point is that there should be a way to specify _what time_ it is
>that is presented as argument, given the insight that there is not only "one
>time" existing. The internal representation should be consistent (say, Unix
>Epoch seconds UTC) and the user interface should allow specifying any "real"
>time to convert from/to internal mtime. UTC, as the standard, is outstanding
>here, but other TZs (as supported with your extension) is valuable as well.

I agree totally with this paragraph as well.

>[*] We should be aware that using ENVIRON["TZ"] to adjust function behaviour
>is bulky, and conceptually reflects very old Fortran programming paradigms,
>i.e. technology used in the 1960's.

I agree totally with this paragraph as well.

--
b w r w g y b r y b

[Andrew Schorr]

On Friday, February 17, 2017 at 9:06:39 AM UTC-5, Janis Papanagnou wrote:
> Wouldn't it make sense if gawk would support UTC in mktime() with an
> optional argument: mktime(datespec [,utc-flag]) ?

Your wish is my command. :-) In 4.2, mktime will have just such an optional argument. If a 2nd argument is present and non-zero or non-null, the calculation will be done in UTC instead of local time.

Thanks for the discussion.

Regards,
Andy

[Ed Morton]

Referee! If you can do that why not just provide strptime() and make mktime()
redundant?

Ed.

[Andrew Schorr]

On Wednesday, February 22, 2017 at 5:23:34 PM UTC-5, Ed Morton wrote:
> Referee! If you can do that why not just provide strptime() and make mktime()
> redundant?

Because mktime is already in gawk, and this constitutes a minor, but helpful, enhancement to its functionality, and is consistent with the strftime utc-flag argument. It will not break any existing code, and there seems to be a demand for this feature.

Providing strptime is a different ball of wax. It's a new function, so it pollutes the namespace and can break existing scripts. And there's no reason that it can't be implemented in an extension. In general, if something can be done in an extension library, then that's where it belongs. As always, we are happy to accept library contributions to the gawkextlib project. I think strptime would be a good candidate for that.

Regards,
Andy

[Kenny McCormack]

In article <42d0d2e3-2b13-49ae...@googlegroups.com>,
Andrew Schorr <asc...@telemetry-investments.com> wrote:
...

>Providing strptime is a different ball of wax. It's a new function, so it
>pollutes the namespace and can break existing scripts. And there's no
>reason that it can't be implemented in an extension. In general, if
>something can be done in an extension library, then that's where it
>belongs. As always, we are happy to accept library contributions to the
>gawkextlib project. I think strptime would be a good candidate for that.

Been there. Done that. Got the T-shirt.

P.S. Not sure why you're even going as far as doing this (enhancing
mktime()), as it also can be (and has been) done in an extension library.

--
Donald Drumpf claims to be "the least racist person you'll ever meet".

This would be true if the only other person you've ever met was David Duke.

[Janis Papanagnou]

On 22.02.2017 23:21, Andrew Schorr wrote:
> On Friday, February 17, 2017 at 9:06:39 AM UTC-5, Janis Papanagnou wrote:
>> Wouldn't it make sense if gawk would support UTC in mktime() with an
>> optional argument: mktime(datespec [,utc-flag]) ?
>
> Your wish is my command. :-) In 4.2, mktime will have just such an optional
> argument. If a 2nd argument is present and non-zero or non-null, the
> calculation will be done in UTC instead of local time.

Glad to hear. I'm relly happy that we will get that feature in native
GNU awk (as opposed to an "external" extension) to support consistent
UTC (standard time) handling with the existing time functions. Thanks!

Janis

[Andrew Schorr]

On Wednesday, February 22, 2017 at 7:29:23 PM UTC-5, Kenny McCormack wrote:
> Been there. Done that. Got the T-shirt.

Ditto.

> P.S. Not sure why you're even going as far as doing this (enhancing
> mktime()), as it also can be (and has been) done in an extension library.

Because this is more convenient. Nobody can even find your extension libraries.

Regards,
Andy

[Kenny McCormack]

In article <bae45066-c2c3-4088...@googlegroups.com>,

Yes they can. I've had many downloads of them.
Including Janis, who has downloaded and compiled my mktime_ex lib.

Obviously, you can do what you want, but this action does contradict
previous public statements by both you & Arnold (on this newsgroup).

--
http://www.rollingstone.com/politics/news/the-10-dumbest-things-ever-said-about-global-warming-20130619

[Janis Papanagnou]

On 24.02.2017 00:41, Kenny McCormack wrote:
> In article <bae45066-c2c3-4088...@googlegroups.com>,
> Andrew Schorr <asc...@telemetry-investments.com> wrote:
>> On Wednesday, February 22, 2017 at 7:29:23 PM UTC-5, Kenny McCormack wrote:
>>> Been there. Done that. Got the T-shirt.
>>
>> Ditto.
>>
>>> P.S. Not sure why you're even going as far as doing this (enhancing
>>> mktime()), as it also can be (and has been) done in an extension library.
>>
>> Because this is more convenient. Nobody can even find your extension libraries.
>
> Yes they can. I've had many downloads of them.
> Including Janis, who has downloaded and compiled my mktime_ex lib.

I think Andrew means that there's no public download page. While I
understand your reason why you don't want a public page it's also
not supportive for contributions that want to address a wider range
of people. (Personally I think that "useful extensions" should be
collected in one place and have some level of quality assurance.
I haven't followed the extensions development too closely, though,
so I don't know whether there is some public repository already
where developers can deposit their code for public access.)

>
> Obviously, you can do what you want, but this action does contradict
> previous public statements by both you & Arnold (on this newsgroup).

I'm not unhappy if that inconsistency in the GNU awk time functions
will be handled that way.

Janis

[Andrew Schorr]

On Thursday, February 23, 2017 at 6:41:49 PM UTC-5, Kenny McCormack wrote:
> Obviously, you can do what you want, but this action does contradict
> previous public statements by both you & Arnold (on this newsgroup).

How so?

[Andrew Schorr]

On Thursday, February 23, 2017 at 7:51:02 PM UTC-5, Janis Papanagnou wrote:
> I think Andrew means that there's no public download page. While I
> understand your reason why you don't want a public page it's also
> not supportive for contributions that want to address a wider range
> of people. (Personally I think that "useful extensions" should be
> collected in one place and have some level of quality assurance.
> I haven't followed the extensions development too closely, though,
> so I don't know whether there is some public repository already
> where developers can deposit their code for public access.)

That is the intention of the gawkextlib project:
https://sourceforge.net/projects/gawkextlib/

For reasons that mystify me, various people on this list have decided that gawkextlib is somehow evil. We live in strange times.

> I'm not unhappy if that inconsistency in the GNU awk time functions
> will be handled that way.

Janis's idea was a good one, so we chose to adopt it. It's a portable enhancement that adds a useful feature without breaking any existing code.

Regards,
Andy

[Kenny McCormack]

In article <84a71a87-0d2c-416e...@googlegroups.com>,
Andrew Schorr <asc...@telemetry-investments.com> wrote:
...

>That is the intention of the gawkextlib project:
>https://sourceforge.net/projects/gawkextlib/
>
>For reasons that mystify me, various people on this list have decided that
>gawkextlib is somehow evil. We live in strange times.

Not evil, per se. But rather "inaccessible to the common man" (i.e., us).

As I will argue at greater length in a future post, I think of gawkextlib
as being like the "juried" section of an Art Fair. Art Fairs generally
have two sections - a "juried" section and the non-juried section (the
rest of the fair). Obviously, for the status-motivated, the juried part
carries more prestige, but whenever we went to these fairs, we always liked
the non-juried parts better. They (the non-juried sections of the Art
Fair) were more "down to earth".

>> I'm not unhappy if that inconsistency in the GNU awk time functions
>> will be handled that way.
>
>Janis's idea was a good one, so we chose to adopt it. It's a portable
>enhancement that adds a useful feature without breaking any existing code.

I get it - although I would argue that it breaks the rule of "if it can be
done in an extension library, it won't be done in the core" (which is what
you and Arnold are on record as saying).

I would also argue that the second arg should be a timezone (e.g., UTC or
America/La_Paz) rather than some kind of binary flag. This allows any
timezone to be used, not just UTC. And note that, as Janis pointed out,
timegm(), which would be the justification for only allowing UTC (i.e., you
can just replace the call to mktime(3) with a call to timegm(3) and be
done), is marked in the man page as "GNU extension or deprecated or
something like that".

I.e., what I am saying is that if you're not going to use timegm(3), you
might as well allow any arbitrary timezone to be passed in.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/DanQuayle

[Kaz Kylheku]

On 2017-02-25, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <84a71a87-0d2c-416e...@googlegroups.com>,
> Andrew Schorr <asc...@telemetry-investments.com> wrote:
> ...
>>That is the intention of the gawkextlib project:
>>https://sourceforge.net/projects/gawkextlib/
>>
>>For reasons that mystify me, various people on this list have decided that
>>gawkextlib is somehow evil. We live in strange times.
>
> Not evil, per se. But rather "inaccessible to the common man" (i.e., us).
>
> As I will argue at greater length in a future post, I think of gawkextlib
> as being like the "juried" section of an Art Fair. Art Fairs generally
> have two sections - a "juried" section and the non-juried section (the
> rest of the fair). Obviously, for the status-motivated, the juried part
> carries more prestige, but whenever we went to these fairs, we always liked
> the non-juried parts better. They (the non-juried sections of the Art
> Fair) were more "down to earth".

No, gawkextlib is that section of the art fair consisting of an exibit
of digital pictures presented on exotic memory cards, not supported
by any hardware that anyone brought to the fair.

[Kenny McCormack]

In article <201702251...@kylheku.com>,

Heh heh. I'm sure Andy would disagree.

I may take another shot at it one of these days. I've not been able to get
it to build yet, but I may have better luck now. I know a little more now
than I once did. I'm still interested in the "Lightning DB" extension,
which, as you may recall, is really what started this whole discussion, way
back when.

Well, that, and Ed's strptime() suggestion...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:

http://user.xmission.com/~gazelle/Sigs/Reaganomics

[Kaz Kylheku]

On 2017-02-25, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <201702251...@kylheku.com>,
> Kaz Kylheku <336-98...@kylheku.com> wrote:
>>On 2017-02-25, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> In article <84a71a87-0d2c-416e...@googlegroups.com>,
>>> Andrew Schorr <asc...@telemetry-investments.com> wrote:
>>> ...
>>>>That is the intention of the gawkextlib project:
>>>>https://sourceforge.net/projects/gawkextlib/
>>>>
>>>>For reasons that mystify me, various people on this list have decided that
>>>>gawkextlib is somehow evil. We live in strange times.
>>>
>>> Not evil, per se. But rather "inaccessible to the common man" (i.e., us).
>>>
>>> As I will argue at greater length in a future post, I think of gawkextlib
>>> as being like the "juried" section of an Art Fair. Art Fairs generally
>>> have two sections - a "juried" section and the non-juried section (the
>>> rest of the fair). Obviously, for the status-motivated, the juried part
>>> carries more prestige, but whenever we went to these fairs, we always liked
>>> the non-juried parts better. They (the non-juried sections of the Art
>>> Fair) were more "down to earth".
>>
>>No, gawkextlib is that section of the art fair consisting of an exibit
>>of digital pictures presented on exotic memory cards, not supported
>>by any hardware that anyone brought to the fair.
>
> Heh heh. I'm sure Andy would disagree.

Warhol? Or that Gawk one above?

[Andrew Schorr]

On Saturday, February 25, 2017 at 12:47:28 PM UTC-5, Kenny McCormack wrote:
> Not evil, per se. But rather "inaccessible to the common man" (i.e., us).

In what way is it inaccessible? Download the tarball, then run './configure && make && make check && make install', just like every other open-source software package in existence. We have gone to great trouble to package this stuff. It's standard and cross-platform. What in the heck is the problem here? It's just like installing gawk!

> As I will argue at greater length in a future post, I think of gawkextlib
> as being like the "juried" section of an Art Fair. Art Fairs generally
> have two sections - a "juried" section and the non-juried section (the
> rest of the fair). Obviously, for the status-motivated, the juried part
> carries more prestige, but whenever we went to these fairs, we always liked
> the non-juried parts better. They (the non-juried sections of the Art
> Fair) were more "down to earth".

You can think of it any way you like, but there is almost zero justification for your point of view. This is an "alternate" viewpoint that has no grounding in facts. If you want to contribute your projects, you are welcome to do so.

> I get it - although I would argue that it breaks the rule of "if it can be
> done in an extension library, it won't be done in the core" (which is what
> you and Arnold are on record as saying).

This is not a new function. And this is not a court of law. I don't recall promising that we would never add any more new features to gawk. We simply expressed a preference for adding new functionality in extension libraries in order to avoid polluting the namespace and to make the code more maintainable. Adding a 2nd argument to mktime to support UTC does not seem to me to violate these "rules".

> I would also argue that the second arg should be a timezone (e.g., UTC or
> America/La_Paz) rather than some kind of binary flag. This allows any
> timezone to be used, not just UTC. And note that, as Janis pointed out,
> timegm(), which would be the justification for only allowing UTC (i.e., you
> can just replace the call to mktime(3) with a call to timegm(3) and be
> done), is marked in the man page as "GNU extension or deprecated or
> something like that".

We are not using timegm, since it is not portable. I see your point about supporting arbitrary timezones, and we considered it. In practice, the vast majority of cases involve the local timezone and UTC. Plus, strftime already set a standard for this behavior with it's UTC flag. So we chose to be consistent with strftime. In 4.2, you can easily tweak the ENVIRON["TZ"] value to support other timezones.

Regards,
Andy

[Andrew Schorr]

On Saturday, February 25, 2017 at 1:22:01 PM UTC-5, Kaz Kylheku wrote:
> No, gawkextlib is that section of the art fair consisting of an exibit
> of digital pictures presented on exotic memory cards, not supported
> by any hardware that anyone brought to the fair.

I don't see any truth or value in this remark. What's "exotic" about delivering open-source software in standard open-source packaging?

Regards,
Andy

[Kenny McCormack]

In article <980a9195-7b7d-4acb...@googlegroups.com>,

I agree. I don't know what drugs Kaz was smoking while posting.

--
Amazingly, it's beginning to look like W is the smart one.

But Jeb will still be the nominee (seriously, who else can/could it be?)

[Kenny McCormack]

In article <2b71ccf5-0854-44be...@googlegroups.com>,

Andrew Schorr <asc...@telemetry-investments.com> wrote:
...

>> As I will argue at greater length in a future post, I think of gawkextlib
>> as being like the "juried" section of an Art Fair. Art Fairs generally
>> have two sections - a "juried" section and the non-juried section (the
>> rest of the fair).

...

>You can think of it any way you like, but there is almost zero
>justification for your point of view. This is an "alternate" viewpoint
>that has no grounding in facts. If you want to contribute your projects,
>you are welcome to do so.

I don't understand this emotional response. I think it is clear that the
analogy is valid - and is not a criticism or anything like that - so I just
must not have presented it correctly.

In any case, I think the juried [*] gawkextlib is what Janis would like to
see, so I encourage him to look into it.

[*] Or perhaps you might prefer the word "curated". Means about the same
thing either way.

--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

[Andrew Schorr]

On Sunday, February 26, 2017 at 12:54:12 PM UTC-5, Kenny McCormack wrote:
> I don't understand this emotional response. I think it is clear that the
> analogy is valid - and is not a criticism or anything like that - so I just
> must not have presented it correctly.
>
> In any case, I think the juried [*] gawkextlib is what Janis would like to
> see, so I encourage him to look into it.
>
> [*] Or perhaps you might prefer the word "curated". Means about the same
> thing either way.

I don't know what you mean by curated/juried. We have never rejected any libraries submitted to the project. The only requirement is that the contributor make the effort to package the code properly. And before you say that nobody other than the main developers has contributed anything, I will point out that this is not correct -- the redis, gd, and haru extensions were not written by the original gawk-xml developers. We are merely trying to provide a centralized location with standardized packaging where people can find useful extensions. If I had the time, I'd want to set up a website where anybody can upload an extension without any involvement from the project maintainers. Unfortunately, I don't see any easy way to do this with SourceForge or Github. I'd love to be able to grant write access to a single subdirectory of the project, but that doesn't seem to be possible. So it's all or nothing. But it's pretty easy for somebody to fork the code, develop a new extension, and then submit a pull request to incorporate the new extension. We've done it a few times.

Regards,
Andy

[Ed Morton]

Last pitch - I completely understand not wanting to add a new function name, but
could you modify mktime() such that if it's called with strptime-like args it
performs the strptime-like function? That shouldn't break anything.

The problem I'm trying to solve is that mktime() only operates one a specific
format of date/time:

YYYY MM DD HH MM SS

so it's [almost?] always necessary for users to do some pre-processing of their
input data to get their date into that format. Commonly given a date like:

28-Jun-2017 9:20PM

we have to write something like (written off the top of my head so you get the
idea, don't worry/care if it's not perfectly correct code):

split($0,t,/[- :]/)
day = t[1]
mth = (match("JanFebMarAprMayJunJulAugSepOctNovDec",t[2])+2)/3
yr = t[3]
hr = t[4] + ((t[5] ~ /PM/) && (t[3] < 12) ? 12 : 0)
min = t[5] + 0
print mktime(yr" "mth" "day" "hr" "min" 0")

which is a PITA to have to write a version of for every input that contains
dates. If we could instead just support (again don't worry if not perfect, just
get the idea):

print mktime($0,"%D-%M-%Y %H:%M%p")

it'd make a big difference to users of gawks time functions and if we had to
make the strptime functionality just a flavor of "mktime" then that's certainly
vastly more useful than not having the functionality!

Ed.

[Andrew Schorr]

On Tuesday, February 28, 2017 at 10:27:06 AM UTC-5, Ed Morton wrote:
> which is a PITA to have to write a version of for every input that contains
> dates.

I sympathize -- I have often had to do the same date transformations in my code.

> If we could instead just support (again don't worry if not perfect, just
> get the idea):
>
> print mktime($0,"%D-%M-%Y %H:%M%p")
>
> it'd make a big difference to users of gawks time functions and if we had to
> make the strptime functionality just a flavor of "mktime" then that's certainly
> vastly more useful than not having the functionality!

I hear you. How portable exactly is the strptime function? Does it work in the native Windows API?

Regards,
Andy

[Ed Morton]

I'm sorry, I don't know but since it's a partner for strftime(), which gawk
obviously already supports, I'd EXPECT the strptime() function to be available
everywhere strftime() is and to work in the native Windows API if strftime()
does. In other words whatever constraints/assumptions are present in gawk wrt
strftime() availability SHOULD apply to strptime() too.

Ed.

[Kenny McCormack]

In article <o96hq6$hk7$1...@dont-email.me>,
Ed Morton <morto...@gmail.com> wrote:
...
(Andy)

>> I hear you. How portable exactly is the strptime function? Does it work
>> in the native Windows API?

(Ed)

>I'm sorry, I don't know but since it's a partner for strftime(), which
>gawk obviously already supports, I'd EXPECT the strptime() function to be
>available everywhere strftime() is and to work in the native Windows API
>if strftime() does. In other words whatever constraints/assumptions are
>present in gawk wrt strftime() availability SHOULD apply to strptime()
>too.

Wrong. I won't give the full chapter/verse, but, basically, strftime() is C,
while strptime() is POSIX.

Anyway, you've been given the solution to this problem many times.
It is always better to do something in your own code than to whine to the
developers that they should do it. As Nike says "Just do it!".

Quiet seriously, I simply don't understand your mental illness when it
comes to your solving this problem.

Finally, note that strptime(3) is itself inherently non-portable. As we
will see shortly, there are subtle differences in its implementation across
various popular Unixes [*].

I can understand the developers unwillingness to commit it to the core.
This suggests further that having people do it themselves, via the extension
functionality, is the proper course of action. The end user (the
writer/maintainer of the extension) then assumes the responsibility for
strptime()'s "non-portable-ness".

[*] Regarding the functionality that Janis originally requested:

The following command line does the right thing (calculates the given date
in GMT, then prints it out in the current timezone) under OSX, but fails
under Linux.

$ gawk4 -l strptime 'BEGIN { print strftime("%c %Z",strptime("GMT 2017 02 14 12 0 0","%Z %Y %m %d %H %M %S"))}'

Under Linux (tested under many different flavors/implementations of Linux),
the strptime(3) call returns NULL, with an error text of:

strptime() returned NULL: Invalid or incomplete multibyte or wide character

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:

http://user.xmission.com/~gazelle/Sigs/Security

[Andrew Schorr]

On Thursday, March 2, 2017 at 6:09:45 AM UTC-5, Kenny McCormack wrote:
> Wrong. I won't give the full chapter/verse, but, basically, strftime() is C,
> while strptime() is POSIX.

Kenny is correct. There's no strptime in Windows. It may be possible to use an open-source strptime implementation, but I don't think this is going to become part of core gawk.

Regards,
Andy

[Ed Morton]

On 3/2/2017 10:37 AM, Andrew Schorr wrote:
> On Thursday, March 2, 2017 at 6:09:45 AM UTC-5, Kenny McCormack wrote:
>> Wrong. I won't give the full chapter/verse, but, basically, strftime() is C,
>> while strptime() is POSIX.
>
> Kenny is correct.

Words that have never been stated before!

> There's no strptime in Windows. It may be possible to use an open-source strptime implementation, but I don't think this is going to become part of core gawk.

OK, thanks for looking into it.

Ed.

> Regards,
> Andy
>

[Kenny McCormack]

In article <o99j12$7h5$1...@dont-email.me>,

Ed Morton <morto...@gmail.com> wrote:
>On 3/2/2017 10:37 AM, Andrew Schorr wrote:
>> On Thursday, March 2, 2017 at 6:09:45 AM UTC-5, Kenny McCormack wrote:
>>> Wrong. I won't give the full chapter/verse, but, basically, strftime() is C,
>>> while strptime() is POSIX.
>>
>> Kenny is correct.
>

>Words that are commonplace in this and other newsgroups.

You're the one with the mental block about fixing this problem for yourself.

I've given you the answer many times now.

--
"There are two things that are important in politics.
The first is money and I can't remember what the second one is."
- Mark Hanna -

[Kenny McCormack]

In article <fd4be3da-b6fe-4292...@googlegroups.com>,

Andrew Schorr <asc...@telemetry-investments.com> wrote:
>On Thursday, March 2, 2017 at 6:09:45 AM UTC-5, Kenny McCormack wrote:
>> Wrong. I won't give the full chapter/verse, but, basically, strftime() is C,
>> while strptime() is POSIX.
>
>Kenny is correct.

Of course.

>There's no strptime in Windows.

But yet I wonder about this. Which Windows compilers do you target?

Doesn't it really depend on the compiler? Obviously, if you use Cygwin, it
will "just work". Not sure about mingw - but as Kaz has shown previously,
there's really no reason to use mingw (as long as Cygwin continues to exist).

And, of course, the elephant in the room, the thing that all the Windows
kids are buzzing about - is the fact that MW has (sort of) embraced POSIX.
The exact details I am not familiar with, but I would assume this means
that if you are running the latest Windows (10) and running whatever is the
latest/greatest compiler/toolchain from MS, POSIX stuff will "just work"
(like it does in Cygwin).

>It may be possible to use an open-source strptime implementation, but I
>don't think this is going to become part of core gawk.

Which leads to my next question. What is the set of targets that GAWK
currently supports - other than, of course, POSIX and Windows ? Are there
versions for z/OS? Burroughs? Unisys?

I see that there is a 'vms' [*] directory out there, so that can be added to
the list of known targets.

[*] In addition to 'posix' and 'pc' directories. A pedant might argue that
the 'pc' directory is misnamed, since it is really Windows. But then
again, what about OS/2? I know that was a supported target in the past.

--
People sleep peaceably in their beds at night only because rough
men stand ready to do violence on their behalf.

George Orwell

[Andrew Schorr]

On Thursday, March 2, 2017 at 12:57:39 PM UTC-5, Kenny McCormack wrote:
> Which leads to my next question. What is the set of targets that GAWK
> currently supports - other than, of course, POSIX and Windows ? Are there
> versions for z/OS? Burroughs? Unisys?

There's a list here:

https://www.gnu.org/software/gawk/manual/html_node/Installation-summary.html

Regards,
Andy

[Kenny McCormack]

In article <445f9552-898d-4d79...@googlegroups.com>,

Which says:

* gawk may be built on non-POSIX systems as well. The currently supported
systems are MS-Windows using MSYS, MinGW, and Cygwin, OS/2 using EMX, and
both Vax/VMS and OpenVMS. Instructions for each system are included in this
appendix.

--
The plural of "anecdote" is _not_ "data".

[Ed Morton]

On 3/2/2017 11:23 AM, Kenny McCormack wrote:
> In article <o99j12$7h5$1...@dont-email.me>,
> Ed Morton <morto...@gmail.com> wrote:
>> On 3/2/2017 10:37 AM, Andrew Schorr wrote:
>>> On Thursday, March 2, 2017 at 6:09:45 AM UTC-5, Kenny McCormack wrote:
>>>> Wrong. I won't give the full chapter/verse, but, basically, strftime() is C,
>>>> while strptime() is POSIX.
>>>
>>> Kenny is correct.
>>
>> Words that are commonplace in this and other newsgroups.

Normally I wouldn't reply to anything you post but - changing the attribution in
a post to make it look like I said something that I didn't? Seriously? Just when
I thought you had stooped as low as you could get you found a way to break
through the floor.

> You're the one with the mental block about fixing this problem for yourself.
>
> I've given you the answer many times now.

I suppose when someone was suggesting to Ford that they fit their cars with
windshield wipers there was an idiot in the background yelling that they just
needed to lean out the side window with a rag. You fill your role nicely. Good
luck with your ranting, churning of subject lines, and manipulating attributions
to feel better about yourself.

Ed.

[Kenny McCormack]

In article <o9aere$745$1...@news.xmission.com>,

BTW, note that for MS Windows, it only includes MSYS/MinGW/Cygwin (All of
which are basically gcc compilers and POSIX-ish environments, ported to
Windows).

Does this mean that so-called "native" C compilers (such as MSVC and the
various "Visual" C products from MS) are *not* supported?

--
If the automobile had followed the same development cycle as the
computer, a Rolls-Royce today would cost $100, get a million miles to
the gallon, and explode once every few weeks, killing everyone inside.

[Andrew Schorr]

On Friday, March 3, 2017 at 6:59:43 PM UTC-5, Kenny McCormack wrote:
> BTW, note that for MS Windows, it only includes MSYS/MinGW/Cygwin (All of
> which are basically gcc compilers and POSIX-ish environments, ported to
> Windows).
>
> Does this mean that so-called "native" C compilers (such as MSVC and the
> various "Visual" C products from MS) are *not* supported?

I don't know the answer to this question. I tried to avoid MS Windows at all costs. Perhaps somebody else knows the answer.

The bottom line is that strptime belongs in an extension, not in core gawk.

Regards,
Andy