Changing GMT Dates to Local Timezone
AC
to translate it to local time zone. The dates are in the yyyy-mm-dd
hh:mm:ss second format, so nothing terribly unusual.
Ed Morton
AC wrote:
> I've got an AWK script that reads in a GMT date from a web log, but I need
> to translate it to local time zone. The dates are in the yyyy-mm-dd
> hh:mm:ss second format, so nothing terribly unusual.
>
Take a look at systime(), mktime(), and strftime() in the gawk manual page.
Ed.
Andrew Schorr
Is this really possible in gawk? If one sets TZ=GMT in the
environment,
one can certainly use the mktime function to convert GMT timestamps to
unix times. But one would then need to switch to the local timezone
before calling strftime to format the local timestamp.
It would be nice if one could say 'ENVIRON["TZ"] = "<local timezone>"'
inside
gawk and have that call putenv or setenv to update the environment.
But I do not see any instances of putenv or setenv in the gawk source,
so it does not seem that updating ENVIRON will actually do the trick.
Am I confused?
Regards,
Andy
Ed Morton
Andrew Schorr wrote:
>
> Ed Morton wrote:
>
>>AC wrote:
>>
>>
>>>I've got an AWK script that reads in a GMT date from a web log, but I need
>>>to translate it to local time zone. The dates are in the yyyy-mm-dd
>>>hh:mm:ss second format, so nothing terribly unusual.
>>>
>>
>>Take a look at systime(), mktime(), and strftime() in the gawk manual page.
>>
<snip>
> It would be nice if one could say 'ENVIRON["TZ"] = "<local timezone>"'
> inside
> gawk and have that call putenv or setenv to update the environment.
> But I do not see any instances of putenv or setenv in the gawk source,
> so it does not seem that updating ENVIRON will actually do the trick.
> Am I confused?
Does this help:
$ gawk 'BEGIN{cdt=strftime()
"TZ=GMT gawk \"BEGIN{print strftime()}\"" | getline gmt
print cdt " -> " gmt}'
Thu Jun 02 09:23:37 CDT 2005 -> Thu Jun 02 14:23:37 GMT 2005
Regards,
Ed.
Ed Morton
Ed Morton wrote:
>
>
> Andrew Schorr wrote:
>
>>
>> Ed Morton wrote:
>>
>>> AC wrote:
>>>
>>>
>>>> I've got an AWK script that reads in a GMT date from a web log, but
>>>> I need
>>>> to translate it to local time zone. The dates are in the yyyy-mm-dd
>>>> hh:mm:ss second format, so nothing terribly unusual.
<snip>
>
> $ gawk 'BEGIN{cdt=strftime()
> "TZ=GMT gawk \"BEGIN{print strftime()}\"" | getline gmt
> print cdt " -> " gmt}'
> Thu Jun 02 09:23:37 CDT 2005 -> Thu Jun 02 14:23:37 GMT 2005
>
> Regards,
>
> Ed.
Another approach that would avoid the need for a recursive call to gawk
would be to use the offset information from TZ to do your own
calculation, e.g.:
$ gawk 'BEGIN{gmt=strftime();
delta=ENVIRON["TZ"]
gsub(/[A-Z]/,"",delta)
cdt=strftime("%a %b %d %H:%M:%S GMT %Y", systime()+(60*60*delta))
print ENVIRON["TZ"] ":" gmt " -> " cdt}'
CST6CDT:Thu Jun 02 09:51:52 CDT 2005 -> Thu Jun 02 15:51:52 GMT 2005
Regards,
Ed.
John DuBois
That'll work as long as both the current time and the log time are in daylight
savings time, or both aren't.
I'd approach this by doing the conversion from GMT timestamp to epoch time
in the awk program, and then using strftime() to print the new timestamp.
The former isn't terribly difficult - see for example isodate2epochday() in
ftp://ftp.armory.com/pub/lib/awk/timedate/epochdays
which will handle the date component (the time component being trivial).
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Ed Morton
John DuBois wrote:
> In article <d7n6qr$e...@netnews.proxy.lucent.com>,
> Ed Morton <mor...@lsupcaemnt.com> wrote:
<snip>
>>$ gawk 'BEGIN{gmt=strftime();
>> delta=ENVIRON["TZ"]
>> gsub(/[A-Z]/,"",delta)
>> cdt=strftime("%a %b %d %H:%M:%S GMT %Y", systime()+(60*60*delta))
>> print ENVIRON["TZ"] ":" gmt " -> " cdt}'
>>CST6CDT:Thu Jun 02 09:51:52 CDT 2005 -> Thu Jun 02 15:51:52 GMT 2005
>
>
> That'll work as long as both the current time and the log time are in daylight
> savings time, or both aren't.
Doesn't the offset get adjusted accordingly? If not, the DST suffix,
when applicable, is present in the TZ variable anyway so it's an easy
tweak to accomodate it.
> I'd approach this by doing the conversion from GMT timestamp to epoch time
> in the awk program, and then using strftime() to print the new timestamp.
That's what the above does, I'm just using "systime()" instead of
creating some imaginary GMT time.
> The former isn't terribly difficult - see for example isodate2epochday() in
> ftp://ftp.armory.com/pub/lib/awk/timedate/epochdays
> which will handle the date component (the time component being trivial).
Call me paranoid, but I have an aversion to downloading things. If you
feel like posting the relevant code.....
Ed.
John DuBois
Ed Morton <mor...@lsupcaemnt.com> wrote:
>
>
>John DuBois wrote:
>> In article <d7n6qr$e...@netnews.proxy.lucent.com>,
>> Ed Morton <mor...@lsupcaemnt.com> wrote:
><snip>
>>>$ gawk 'BEGIN{gmt=strftime();
>>> delta=ENVIRON["TZ"]
>>> gsub(/[A-Z]/,"",delta)
>>> cdt=strftime("%a %b %d %H:%M:%S GMT %Y", systime()+(60*60*delta))
>>> print ENVIRON["TZ"] ":" gmt " -> " cdt}'
>>>CST6CDT:Thu Jun 02 09:51:52 CDT 2005 -> Thu Jun 02 15:51:52 GMT 2005
>>
>>
>> That'll work as long as both the current time and the log time are in daylight
>> savings time, or both aren't.
>
>Doesn't the offset get adjusted accordingly? If not, the DST suffix,
>when applicable, is present in the TZ variable anyway so it's an easy
>tweak to accomodate it.
>
>> I'd approach this by doing the conversion from GMT timestamp to epoch time
>> in the awk program, and then using strftime() to print the new timestamp.
>
>That's what the above does, I'm just using "systime()" instead of
>creating some imaginary GMT time.
My interpretation from your earlier posts was that in this example systime()
was standing in for an invokation of mktime(), which is different from the
conversion I referred to in that mktime() will apply a timezone offset that is
incorrect (since the time you're giving it isn't actually in the local
timezone) and which can be difficult to undo - best to avoid it if possible. I
use mktime() when I *want* its knowledge of all the goofy things that go on
with timezones and DST and such. In this case that's exactly what *isn't*
wanted, and the conversion of a UTC date to epoch time is relatively easy.
>> The former isn't terribly difficult - see for example isodate2epochday() in
>> ftp://ftp.armory.com/pub/lib/awk/timedate/epochdays
>> which will handle the date component (the time component being trivial).
>
>Call me paranoid, but I have an aversion to downloading things. If you
>feel like posting the relevant code.....
It's just text. If you give your web browser that URL it should display it
just like any other web page, and no more dangerously.
Andrew Schorr
if the TZ
variable happens to embed the GMT offset.
It would be nice if gawk could manipulate the environment to allow
calling mktime
with one value for TZ and then strftime after changing TZ. It would
not be
too hard to write a shared library extension for xgawk to do this
(implementing
setenv and unsetenv). Check out
http://sourceforge.net/projects/xmlgawk
for a version of gawk that is easily extendable...
Regards,
Andy
Patrick TJ McPhee
Andrew Schorr <asc...@telemetry-investments.com> wrote:
% with one value for TZ and then strftime after changing TZ. It would
% not be
% too hard to write a shared library extension for xgawk to do this
% (implementing
% setenv and unsetenv). Check out
% http://sourceforge.net/projects/xmlgawk
% for a version of gawk that is easily extendable...
How is it easier to extend than the standard version?
--
Patrick TJ McPhee
North York Canada
pt...@interlog.com
Andrew Schorr
regular gawk. Here are
the noticeable differences:
1. Support for @include is now part of the gawk lexer, so the igawk
script is no longer necessary.
This makes it easy and efficient to have gawk source code libraries
installed in a standard location.
And there is a new -i (--include) command-line option that has the same
effect as @include.
2. Adds support for a new @load directive to load a shared library.
This is similar to using
the gawk 3.1.4 extension function, but the syntax is closer to @include
and tries to make the
use of source and object libraries more similar. And there is a new -l
(--load) command-line
option that has the same effect as @load.
3. Automatic search path (environment variable AWKLIBPATH) for shared
libraries.
This defaults to an appropriate value, so it is no longer necessary to
specify the
full path to the extension function. Also, the default shared library
suffix is automatically
used, so it does not need to be specified in the gawk code.
4. Automatic ".awk" suffix completion for source code files loaded
using -f, -i, or @include.
This feature has been present for a while but was commented out.
5. Enhances the build infrastructure to use libtool to properly build
shared libraries included
in the extension subdirectory of the distro. So the filefuncs, fork,
ordchr, and readfile
extensions are now built and installed automatically.
6. Adds 2 major new shared libraries: an XML parsing library using
expat, and an interface
to PostgreSQL using libpq.
So, for example, I am currently using xgawk to load XML data into a
PostgreSQL database.
I hope that explains it, unfortunately the xgawk documentation is not
fully mature yet (in particular,
I haven't written any PostgreSQL documentation yet, but it's basically
just a wrapper around
libpq).
Regards,
Andy