Bug #127930 for Amazon-Credentials: t/02-credentials.t fails on some systems

Wed Dec 05 16:20:02 2018 SREZIC [...] cpan.org - Ticket created

Subject:

t/02-credentials.t fails on some systems

On my freebsd10 and freebsd11 smokers t/02-credentials.t fails: ... # Failed test 'is_token_expired() - no?' # at t/02-credentials.t line 72. # Failed test 'refresh_token()' # at t/02-credentials.t line 94. # Looks like you failed 2 tests of 6. t/02-credentials.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/6 subtests ...

Wed Dec 05 16:29:34 2018 BIGFOOT [...] cpan.org - Correspondence added

Hmm..yes I saw that..puzzling as the test works on other versions and distros from what I can see in the test reports. The test attempts to determine if a token has timed out by looking at the token expiration time compared to the current time. I'll take a closer look at how my comparisons are being done and why it appears that it is busted only on versions > 5.20.0 and only on freebsd. Puzzling indeed. On Wed Dec 05 16:20:02 2018, SREZIC wrote: Show quoted text

> On my freebsd10 and freebsd11 smokers t/02-credentials.t fails: > > ... > # Failed test 'is_token_expired() - no?' > # at t/02-credentials.t line 72. > > # Failed test 'refresh_token()' > # at t/02-credentials.t line 94. > # Looks like you failed 2 tests of 6. > t/02-credentials.t .. > Dubious, test returned 2 (wstat 512, 0x200) > Failed 2/6 subtests > ...

Wed Dec 05 16:29:35 2018 The RT System itself - Status changed from 'new' to 'open'

Wed Dec 05 17:25:15 2018 SREZIC [...] cpan.org - Correspondence added

Maybe it's timezone related? I just tried setting TZ=UTC (originally the freebsd10 system has Europe/Berlin configured), and now the tests pass... On 2018-12-05 16:29:34, BIGFOOT wrote: Show quoted text

> Hmm..yes I saw that..puzzling as the test works on other versions and > distros from what I can see in the test reports. The test attempts to > determine if a token has timed out by looking at the token expiration > time compared to the current time. I'll take a closer look at how my > comparisons are being done and why it appears that it is busted only > on versions > 5.20.0 and only on freebsd. > > Puzzling indeed. > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > On my freebsd10 and freebsd11 smokers t/02-credentials.t fails: > > > > ... > > # Failed test 'is_token_expired() - no?' > > # at t/02-credentials.t line 72. > > > > # Failed test 'refresh_token()' > > # at t/02-credentials.t line 94. > > # Looks like you failed 2 tests of 6. > > t/02-credentials.t .. > > Dubious, test returned 2 (wstat 512, 0x200) > > Failed 2/6 subtests > > ...

Wed Dec 05 22:05:57 2018 BIGFOOT [...] cpan.org - Correspondence added

Yes, that's the working theory - I've uploaded a new version 1.0.8 which I believe addresses the root cause - incorrect parsing of the ISO8601 date format using strptime(). Let's see how this one fares. On Wed Dec 05 17:25:15 2018, SREZIC wrote: Show quoted text

> Maybe it's timezone related? I just tried setting TZ=UTC (originally > the freebsd10 system has Europe/Berlin configured), and now the tests > pass... > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > Hmm..yes I saw that..puzzling as the test works on other versions and > > distros from what I can see in the test reports. The test attempts > > to > > determine if a token has timed out by looking at the token expiration > > time compared to the current time. I'll take a closer look at how my > > comparisons are being done and why it appears that it is busted only > > on versions > 5.20.0 and only on freebsd. > > > > Puzzling indeed. > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > On my freebsd10 and freebsd11 smokers t/02-credentials.t fails: > > > > > > ... > > > # Failed test 'is_token_expired() - no?' > > > # at t/02-credentials.t line 72. > > > > > > # Failed test 'refresh_token()' > > > # at t/02-credentials.t line 94. > > > # Looks like you failed 2 tests of 6. > > > t/02-credentials.t .. > > > Dubious, test returned 2 (wstat 512, 0x200) > > > Failed 2/6 subtests > > > ...

Thu Dec 06 01:46:24 2018 SREZIC [...] cpan.org - Correspondence added

Now it passes on the previously failing freebsd systems (10 + 11), but it fails now with freebsd 12 + 13. A sample report: http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8-9416-c1ac4f889b37 On 2018-12-05 22:05:57, BIGFOOT wrote: Show quoted text

> Yes, that's the working theory - I've uploaded a new version 1.0.8 > which I believe addresses the root cause - incorrect parsing of the > ISO8601 date format using strptime(). Let's see how this one fares. > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > Maybe it's timezone related? I just tried setting TZ=UTC (originally > > the freebsd10 system has Europe/Berlin configured), and now the tests > > pass... > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > Hmm..yes I saw that..puzzling as the test works on other versions > > > and > > > distros from what I can see in the test reports. The test attempts > > > to > > > determine if a token has timed out by looking at the token > > > expiration > > > time compared to the current time. I'll take a closer look at how > > > my > > > comparisons are being done and why it appears that it is busted > > > only > > > on versions > 5.20.0 and only on freebsd. > > > > > > Puzzling indeed. > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > On my freebsd10 and freebsd11 smokers t/02-credentials.t fails: > > > > > > > > ... > > > > # Failed test 'is_token_expired() - no?' > > > > # at t/02-credentials.t line 72. > > > > > > > > # Failed test 'refresh_token()' > > > > # at t/02-credentials.t line 94. > > > > # Looks like you failed 2 tests of 6. > > > > t/02-credentials.t .. > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > Failed 2/6 subtests > > > > ...

Thu Dec 06 11:38:52 2018 BIGFOOT [...] cpan.org - Correspondence added

Show quoted text

> Now it passes on the previously failing freebsd systems (10 + 11), but > it fails now with freebsd 12 + 13. A sample report:

Wow, fun stuff. I'm not sure I necessarily believe that the version of freebsd 12/13 is the issue - but I do not have access to those distros at the moment. My inclination is that my test is bad? Oddly though the diagnostics tell me that the expiration date and current time are exactly 5 seconds apart (still exactly within the valid token time window) - which means that when is_token_expired() did the same conversions the time left should be 5s. If this were a timing issue I would have expected the diagnostics to tell me the diff between expiration time and current time was > 5 seconds. # $VAR1 = [ # '2018-12-06T03:52:14Z', # '2018-12-06T03:47:09Z' # ]; ...so almost certainly I must be seeing some drift from timegm()? Any chance you can run this little snippet in those problem envs? #!/usr/bin/perl use strict; use warnings; use Time::Local; use POSIX::strptime qw/strptime/; use Date::Format; # notes: # - expect UTC == GMT, EDT <> UTC # - UTC is not really time zone, so maybe issue on some platforms, better to use GMT? # - EDT should not be the same since my ISO8610 is Zulu time...just for sanity foreach my $tz (qw/UTC GMT EDT/) { my $time = time; my $iso8610 = time2str("%Y-%m-%dT%H:%M:%SZ", $time, $tz); my $timegm = timegm(strptime($iso8610, "%Y-%m-%dT%H:%M:%S%z")); printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n%s\n", $tz, $iso8610, $time, $timegm, '-'x60); } ...if not I will add some additional diagnostics and a debug flag for testing On Thu Dec 06 01:46:24 2018, SREZIC wrote: Show quoted text

> Now it passes on the previously failing freebsd systems (10 + 11), but > it fails now with freebsd 12 + 13. A sample report: > http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8-9416- > c1ac4f889b37 > > On 2018-12-05 22:05:57, BIGFOOT wrote:

> > Yes, that's the working theory - I've uploaded a new version 1.0.8 > > which I believe addresses the root cause - incorrect parsing of the > > ISO8601 date format using strptime(). Let's see how this one fares. > > > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > > Maybe it's timezone related? I just tried setting TZ=UTC > > > (originally > > > the freebsd10 system has Europe/Berlin configured), and now the > > > tests > > > pass... > > > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > > Hmm..yes I saw that..puzzling as the test works on other versions > > > > and > > > > distros from what I can see in the test reports. The test > > > > attempts > > > > to > > > > determine if a token has timed out by looking at the token > > > > expiration > > > > time compared to the current time. I'll take a closer look at > > > > how > > > > my > > > > comparisons are being done and why it appears that it is busted > > > > only > > > > on versions > 5.20.0 and only on freebsd. > > > > > > > > Puzzling indeed. > > > > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > > On my freebsd10 and freebsd11 smokers t/02-credentials.t fails: > > > > > > > > > > ... > > > > > # Failed test 'is_token_expired() - no?' > > > > > # at t/02-credentials.t line 72. > > > > > > > > > > # Failed test 'refresh_token()' > > > > > # at t/02-credentials.t line 94. > > > > > # Looks like you failed 2 tests of 6. > > > > > t/02-credentials.t .. > > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > > Failed 2/6 subtests > > > > > ...

Thu Dec 06 11:38:53 2018 BIGFOOT [...] cpan.org - Fixed in 1.0.8 added

Sat Dec 08 09:16:25 2018 BIGFOOT [...] cpan.org - Correspondence added

re-opening issue, still fails on subset of freebsd distros

Sat Dec 08 09:16:26 2018 BIGFOOT [...] cpan.org - Status changed from 'open' to 'stalled'

Sat Dec 08 10:32:10 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-12-06 11:38:52, BIGFOOT wrote: Show quoted text

> > Now it passes on the previously failing freebsd systems (10 + 11), > > but > > it fails now with freebsd 12 + 13. A sample report:

> > Wow, fun stuff. I'm not sure I necessarily believe that the version > of freebsd 12/13 is the issue - but I do not have access to those > distros at the moment. My inclination is that my test is bad? > > Oddly though the diagnostics tell me that the expiration date and > current time are exactly 5 seconds apart (still exactly within the > valid token time window) - which means that when is_token_expired() > did the same conversions the time left should be 5s. If this were a > timing issue I would have expected the diagnostics to tell me the diff > between expiration time and current time was > 5 seconds. > > # $VAR1 = [ > # '2018-12-06T03:52:14Z', > # '2018-12-06T03:47:09Z' > # ]; > > > ...so almost certainly I must be seeing some drift from timegm()? > > Any chance you can run this little snippet in those problem envs? > > #!/usr/bin/perl > > use strict; > use warnings; > > use Time::Local; > use POSIX::strptime qw/strptime/; > use Date::Format; > > # notes: > # - expect UTC == GMT, EDT <> UTC > # - UTC is not really time zone, so maybe issue on some platforms, > better to use GMT? > # - EDT should not be the same since my ISO8610 is Zulu time...just > for sanity > > foreach my $tz (qw/UTC GMT EDT/) { > my $time = time; > my $iso8610 = time2str("%Y-%m-%dT%H:%M:%SZ", $time, $tz); > my $timegm = timegm(strptime($iso8610, "%Y-%m-%dT%H:%M:%S%z")); > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n%s\n", $tz, > $iso8610, $time, $timegm, '-'x60); > } > > ...if not I will add some additional diagnostics and a debug flag for > testing

The test script surely returns something unexpected on freebsd 12 + 13: TZ: UTC ISO8601: 2018-12-08T15:30:26Z time: 1544283026 timegm: 976289426 ------------------------------------------------------------ TZ: GMT ISO8601: 2018-12-08T15:30:26Z time: 1544283026 timegm: 976289426 ------------------------------------------------------------ TZ: EDT ISO8601: 2018-12-08T11:30:26Z time: 1544283026 timegm: 976275026 ------------------------------------------------------------ It seems that the year field in the strptime output is broken. Here a working strptime on freebsd 11: $ perl -MPOSIX::strptime=strptime -e 'warn join ",", strptime("2018-12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' 10,10,10,10,11,118,6,341, at -e line 1. Here the bad output on freebsd 12: $ perl -MPOSIX::strptime=strptime -e 'warn join ",", strptime("2018-12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' 10,10,10,10,11,,6,341, at -e line 1. Show quoted text

> > On Thu Dec 06 01:46:24 2018, SREZIC wrote:

> > Now it passes on the previously failing freebsd systems (10 + 11), > > but > > it fails now with freebsd 12 + 13. A sample report: > > http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8-9416- > > c1ac4f889b37 > > > > On 2018-12-05 22:05:57, BIGFOOT wrote:

> > > Yes, that's the working theory - I've uploaded a new version 1.0.8 > > > which I believe addresses the root cause - incorrect parsing of the > > > ISO8601 date format using strptime(). Let's see how this one > > > fares. > > > > > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > > > Maybe it's timezone related? I just tried setting TZ=UTC > > > > (originally > > > > the freebsd10 system has Europe/Berlin configured), and now the > > > > tests > > > > pass... > > > > > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > > > Hmm..yes I saw that..puzzling as the test works on other > > > > > versions > > > > > and > > > > > distros from what I can see in the test reports. The test > > > > > attempts > > > > > to > > > > > determine if a token has timed out by looking at the token > > > > > expiration > > > > > time compared to the current time. I'll take a closer look at > > > > > how > > > > > my > > > > > comparisons are being done and why it appears that it is busted > > > > > only > > > > > on versions > 5.20.0 and only on freebsd. > > > > > > > > > > Puzzling indeed. > > > > > > > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > > > On my freebsd10 and freebsd11 smokers t/02-credentials.t > > > > > > fails: > > > > > > > > > > > > ... > > > > > > # Failed test 'is_token_expired() - no?' > > > > > > # at t/02-credentials.t line 72. > > > > > > > > > > > > # Failed test 'refresh_token()' > > > > > > # at t/02-credentials.t line 94. > > > > > > # Looks like you failed 2 tests of 6. > > > > > > t/02-credentials.t .. > > > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > > > Failed 2/6 subtests > > > > > > ...

Sat Dec 08 10:32:10 2018 The RT System itself - Status changed from 'stalled' to 'open'

Sat Dec 08 10:39:14 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-12-08 10:32:10, SREZIC wrote: Show quoted text

> On 2018-12-06 11:38:52, BIGFOOT wrote:

> > > Now it passes on the previously failing freebsd systems (10 + 11), > > > but > > > it fails now with freebsd 12 + 13. A sample report:

> > > > Wow, fun stuff. I'm not sure I necessarily believe that the version > > of freebsd 12/13 is the issue - but I do not have access to those > > distros at the moment. My inclination is that my test is bad? > > > > Oddly though the diagnostics tell me that the expiration date and > > current time are exactly 5 seconds apart (still exactly within the > > valid token time window) - which means that when is_token_expired() > > did the same conversions the time left should be 5s. If this were a > > timing issue I would have expected the diagnostics to tell me the > > diff > > between expiration time and current time was > 5 seconds. > > > > # $VAR1 = [ > > # '2018-12-06T03:52:14Z', > > # '2018-12-06T03:47:09Z' > > # ]; > > > > > > ...so almost certainly I must be seeing some drift from timegm()? > > > > Any chance you can run this little snippet in those problem envs? > > > > #!/usr/bin/perl > > > > use strict; > > use warnings; > > > > use Time::Local; > > use POSIX::strptime qw/strptime/; > > use Date::Format; > > > > # notes: > > # - expect UTC == GMT, EDT <> UTC > > # - UTC is not really time zone, so maybe issue on some platforms, > > better to use GMT? > > # - EDT should not be the same since my ISO8610 is Zulu time...just > > for sanity > > > > foreach my $tz (qw/UTC GMT EDT/) { > > my $time = time; > > my $iso8610 = time2str("%Y-%m-%dT%H:%M:%SZ", $time, $tz); > > my $timegm = timegm(strptime($iso8610, "%Y-%m-%dT%H:%M:%S%z")); > > > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n%s\n", $tz, > > $iso8610, $time, $timegm, '-'x60); > > } > > > > ...if not I will add some additional diagnostics and a debug flag for > > testing

> > The test script surely returns something unexpected on freebsd 12 + > 13: > > TZ: UTC ISO8601: 2018-12-08T15:30:26Z > time: 1544283026 > timegm: 976289426 > ------------------------------------------------------------ > TZ: GMT ISO8601: 2018-12-08T15:30:26Z > time: 1544283026 > timegm: 976289426 > ------------------------------------------------------------ > TZ: EDT ISO8601: 2018-12-08T11:30:26Z > time: 1544283026 > timegm: 976275026 > ------------------------------------------------------------ > > > It seems that the year field in the strptime output is broken. Here a > working strptime on freebsd 11: > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", strptime("2018- > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > 10,10,10,10,11,118,6,341, at -e line 1. > > Here the bad output on freebsd 12: > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", strptime("2018- > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > 10,10,10,10,11,,6,341, at -e line 1. >

A FreeBSD bug? I tried a C program: #include <time.h> #include <stdio.h> int main() { struct tm tm; printf("ret=%s\n", strptime("2018-12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z", &tm)); printf("year=%d\n", tm.tm_year); } Output on FreeBSD 11: ret=(null) year=118 Output on FreeBSD 12: ret=(null) year=0 Show quoted text

> > > > On Thu Dec 06 01:46:24 2018, SREZIC wrote:

> > > Now it passes on the previously failing freebsd systems (10 + 11), > > > but > > > it fails now with freebsd 12 + 13. A sample report: > > > http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8-9416- > > > c1ac4f889b37 > > > > > > On 2018-12-05 22:05:57, BIGFOOT wrote:

> > > > Yes, that's the working theory - I've uploaded a new version > > > > 1.0.8 > > > > which I believe addresses the root cause - incorrect parsing of > > > > the > > > > ISO8601 date format using strptime(). Let's see how this one > > > > fares. > > > > > > > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > > > > Maybe it's timezone related? I just tried setting TZ=UTC > > > > > (originally > > > > > the freebsd10 system has Europe/Berlin configured), and now the > > > > > tests > > > > > pass... > > > > > > > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > > > > Hmm..yes I saw that..puzzling as the test works on other > > > > > > versions > > > > > > and > > > > > > distros from what I can see in the test reports. The test > > > > > > attempts > > > > > > to > > > > > > determine if a token has timed out by looking at the token > > > > > > expiration > > > > > > time compared to the current time. I'll take a closer look > > > > > > at > > > > > > how > > > > > > my > > > > > > comparisons are being done and why it appears that it is > > > > > > busted > > > > > > only > > > > > > on versions > 5.20.0 and only on freebsd. > > > > > > > > > > > > Puzzling indeed. > > > > > > > > > > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > > > > On my freebsd10 and freebsd11 smokers t/02-credentials.t > > > > > > > fails: > > > > > > > > > > > > > > ... > > > > > > > # Failed test 'is_token_expired() - no?' > > > > > > > # at t/02-credentials.t line 72. > > > > > > > > > > > > > > # Failed test 'refresh_token()' > > > > > > > # at t/02-credentials.t line 94. > > > > > > > # Looks like you failed 2 tests of 6. > > > > > > > t/02-credentials.t .. > > > > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > > > > Failed 2/6 subtests > > > > > > > ...

Sat Dec 08 11:03:07 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-12-08 10:39:14, SREZIC wrote: Show quoted text

> On 2018-12-08 10:32:10, SREZIC wrote:

> > On 2018-12-06 11:38:52, BIGFOOT wrote:

> > > > Now it passes on the previously failing freebsd systems (10 + > > > > 11), > > > > but > > > > it fails now with freebsd 12 + 13. A sample report:

> > > > > > Wow, fun stuff. I'm not sure I necessarily believe that the > > > version > > > of freebsd 12/13 is the issue - but I do not have access to those > > > distros at the moment. My inclination is that my test is bad? > > > > > > Oddly though the diagnostics tell me that the expiration date and > > > current time are exactly 5 seconds apart (still exactly within the > > > valid token time window) - which means that when is_token_expired() > > > did the same conversions the time left should be 5s. If this were > > > a > > > timing issue I would have expected the diagnostics to tell me the > > > diff > > > between expiration time and current time was > 5 seconds. > > > > > > # $VAR1 = [ > > > # '2018-12-06T03:52:14Z', > > > # '2018-12-06T03:47:09Z' > > > # ]; > > > > > > > > > ...so almost certainly I must be seeing some drift from timegm()? > > > > > > Any chance you can run this little snippet in those problem envs? > > > > > > #!/usr/bin/perl > > > > > > use strict; > > > use warnings; > > > > > > use Time::Local; > > > use POSIX::strptime qw/strptime/; > > > use Date::Format; > > > > > > # notes: > > > # - expect UTC == GMT, EDT <> UTC > > > # - UTC is not really time zone, so maybe issue on some platforms, > > > better to use GMT? > > > # - EDT should not be the same since my ISO8610 is Zulu time...just > > > for sanity > > > > > > foreach my $tz (qw/UTC GMT EDT/) { > > > my $time = time; > > > my $iso8610 = time2str("%Y-%m-%dT%H:%M:%SZ", $time, $tz); > > > my $timegm = timegm(strptime($iso8610, "%Y-%m-%dT%H:%M:%S%z")); > > > > > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n%s\n", $tz, > > > $iso8610, $time, $timegm, '-'x60); > > > } > > > > > > ...if not I will add some additional diagnostics and a debug flag > > > for > > > testing

> > > > The test script surely returns something unexpected on freebsd 12 + > > 13: > > > > TZ: UTC ISO8601: 2018-12-08T15:30:26Z > > time: 1544283026 > > timegm: 976289426 > > ------------------------------------------------------------ > > TZ: GMT ISO8601: 2018-12-08T15:30:26Z > > time: 1544283026 > > timegm: 976289426 > > ------------------------------------------------------------ > > TZ: EDT ISO8601: 2018-12-08T11:30:26Z > > time: 1544283026 > > timegm: 976275026 > > ------------------------------------------------------------ > > > > > > It seems that the year field in the strptime output is broken. Here a > > working strptime on freebsd 11: > > > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", strptime("2018- > > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > > 10,10,10,10,11,118,6,341, at -e line 1. > > > > Here the bad output on freebsd 12: > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", strptime("2018- > > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > > 10,10,10,10,11,,6,341, at -e line 1. > >

> > A FreeBSD bug? I tried a C program: > > #include <time.h> > #include <stdio.h> > > int main() { > struct tm tm; > printf("ret=%s\n", strptime("2018-12-10T10:10:10Z", "%Y-%m- > %dT%H:%M:%S%z", &tm)); > printf("year=%d\n", tm.tm_year); > } > > > Output on FreeBSD 11: > > ret=(null) > year=118 > > > Output on FreeBSD 12: > > ret=(null) > year=0 >

Well, reading the strptime and strftime manpages on linux & freebsd I am not sure that "Z" is supposed to be parsed by "%z". strptime returned NULL in the example c program in both cases, which indicates a parse error. It seems coincidence that the tm contents were already filled correctly on linux and freebsd <= 11. But in freebsd 12 and newer tm->tm_year is filled later (if I understand https://svnweb.freebsd.org/base/head/lib/libc/stdtime/strptime.c?view=markup&pathrev=340106 correctly), so here the year field is just left zero. What's probably safe is to use "+00:00" instead of "Z" here. Show quoted text

> > > > > > On Thu Dec 06 01:46:24 2018, SREZIC wrote:

> > > > Now it passes on the previously failing freebsd systems (10 + > > > > 11), > > > > but > > > > it fails now with freebsd 12 + 13. A sample report: > > > > http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8-9416- > > > > c1ac4f889b37 > > > > > > > > On 2018-12-05 22:05:57, BIGFOOT wrote:

> > > > > Yes, that's the working theory - I've uploaded a new version > > > > > 1.0.8 > > > > > which I believe addresses the root cause - incorrect parsing of > > > > > the > > > > > ISO8601 date format using strptime(). Let's see how this one > > > > > fares. > > > > > > > > > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > > > > > Maybe it's timezone related? I just tried setting TZ=UTC > > > > > > (originally > > > > > > the freebsd10 system has Europe/Berlin configured), and now > > > > > > the > > > > > > tests > > > > > > pass... > > > > > > > > > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > > > > > Hmm..yes I saw that..puzzling as the test works on other > > > > > > > versions > > > > > > > and > > > > > > > distros from what I can see in the test reports. The test > > > > > > > attempts > > > > > > > to > > > > > > > determine if a token has timed out by looking at the token > > > > > > > expiration > > > > > > > time compared to the current time. I'll take a closer look > > > > > > > at > > > > > > > how > > > > > > > my > > > > > > > comparisons are being done and why it appears that it is > > > > > > > busted > > > > > > > only > > > > > > > on versions > 5.20.0 and only on freebsd. > > > > > > > > > > > > > > Puzzling indeed. > > > > > > > > > > > > > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > > > > > On my freebsd10 and freebsd11 smokers t/02-credentials.t > > > > > > > > fails: > > > > > > > > > > > > > > > > ... > > > > > > > > # Failed test 'is_token_expired() - no?' > > > > > > > > # at t/02-credentials.t line 72. > > > > > > > > > > > > > > > > # Failed test 'refresh_token()' > > > > > > > > # at t/02-credentials.t line 94. > > > > > > > > # Looks like you failed 2 tests of 6. > > > > > > > > t/02-credentials.t .. > > > > > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > > > > > Failed 2/6 subtests > > > > > > > > ...

Sat Dec 08 11:53:40 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-12-08 11:03:07, SREZIC wrote: Show quoted text

> On 2018-12-08 10:39:14, SREZIC wrote:

> > On 2018-12-08 10:32:10, SREZIC wrote:

> > > On 2018-12-06 11:38:52, BIGFOOT wrote:

> > > > > Now it passes on the previously failing freebsd systems (10 + > > > > > 11), > > > > > but > > > > > it fails now with freebsd 12 + 13. A sample report:

> > > > > > > > Wow, fun stuff. I'm not sure I necessarily believe that the > > > > version > > > > of freebsd 12/13 is the issue - but I do not have access to those > > > > distros at the moment. My inclination is that my test is bad? > > > > > > > > Oddly though the diagnostics tell me that the expiration date and > > > > current time are exactly 5 seconds apart (still exactly within > > > > the > > > > valid token time window) - which means that when > > > > is_token_expired() > > > > did the same conversions the time left should be 5s. If this > > > > were > > > > a > > > > timing issue I would have expected the diagnostics to tell me the > > > > diff > > > > between expiration time and current time was > 5 seconds. > > > > > > > > # $VAR1 = [ > > > > # '2018-12-06T03:52:14Z', > > > > # '2018-12-06T03:47:09Z' > > > > # ]; > > > > > > > > > > > > ...so almost certainly I must be seeing some drift from timegm()? > > > > > > > > Any chance you can run this little snippet in those problem envs? > > > > > > > > #!/usr/bin/perl > > > > > > > > use strict; > > > > use warnings; > > > > > > > > use Time::Local; > > > > use POSIX::strptime qw/strptime/; > > > > use Date::Format; > > > > > > > > # notes: > > > > # - expect UTC == GMT, EDT <> UTC > > > > # - UTC is not really time zone, so maybe issue on some > > > > platforms, > > > > better to use GMT? > > > > # - EDT should not be the same since my ISO8610 is Zulu > > > > time...just > > > > for sanity > > > > > > > > foreach my $tz (qw/UTC GMT EDT/) { > > > > my $time = time; > > > > my $iso8610 = time2str("%Y-%m-%dT%H:%M:%SZ", $time, $tz); > > > > my $timegm = timegm(strptime($iso8610, "%Y-%m-%dT%H:%M:%S%z")); > > > > > > > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n%s\n", $tz, > > > > $iso8610, $time, $timegm, '-'x60); > > > > } > > > > > > > > ...if not I will add some additional diagnostics and a debug flag > > > > for > > > > testing

> > > > > > The test script surely returns something unexpected on freebsd 12 + > > > 13: > > > > > > TZ: UTC ISO8601: 2018-12-08T15:30:26Z > > > time: 1544283026 > > > timegm: 976289426 > > > ------------------------------------------------------------ > > > TZ: GMT ISO8601: 2018-12-08T15:30:26Z > > > time: 1544283026 > > > timegm: 976289426 > > > ------------------------------------------------------------ > > > TZ: EDT ISO8601: 2018-12-08T11:30:26Z > > > time: 1544283026 > > > timegm: 976275026 > > > ------------------------------------------------------------ > > > > > > > > > It seems that the year field in the strptime output is broken. Here > > > a > > > working strptime on freebsd 11: > > > > > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", > > > strptime("2018- > > > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > > > 10,10,10,10,11,118,6,341, at -e line 1. > > > > > > Here the bad output on freebsd 12: > > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", > > > strptime("2018- > > > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > > > 10,10,10,10,11,,6,341, at -e line 1. > > >

> > > > A FreeBSD bug? I tried a C program: > > > > #include <time.h> > > #include <stdio.h> > > > > int main() { > > struct tm tm; > > printf("ret=%s\n", strptime("2018-12-10T10:10:10Z", "%Y-%m- > > %dT%H:%M:%S%z", &tm)); > > printf("year=%d\n", tm.tm_year); > > } > > > > > > Output on FreeBSD 11: > > > > ret=(null) > > year=118 > > > > > > Output on FreeBSD 12: > > > > ret=(null) > > year=0 > >

> > Well, reading the strptime and strftime manpages on linux & freebsd I > am not sure that "Z" is supposed to be parsed by "%z". strptime > returned NULL in the example c program in both cases, which indicates > a parse error. It seems coincidence that the tm contents were already > filled correctly on linux and freebsd <= 11. But in freebsd 12 and > newer tm->tm_year is filled later (if I understand > https://svnweb.freebsd.org/base/head/lib/libc/stdtime/strptime.c?view=markup&pathrev=340106 > correctly), so here the year field is just left zero. > > What's probably safe is to use "+00:00" instead of "Z" here. >

The CPAN module POSIX::2008 also provides a strptime function, and this one just return undef for %z=Z. %z=+00:00 works: $ perl5.26.1 -MPOSIX::2008=strptime -e 'warn join(",", strptime("2018-10-10T12:34:45+00:00", "%Y-%m-%dT%H:%M:%S%z"))' 45,34,12,10,9,118,3,282,-1 at -e line 1. $ perl5.26.1 -MPOSIX::2008=strptime -e 'warn join(",", strptime("2018-10-10T12:34:45Z", "%Y-%m-%dT%H:%M:%S%z"))' Warning: something's wrong at -e line 1. Show quoted text

> >

> > > > > > > > On Thu Dec 06 01:46:24 2018, SREZIC wrote:

> > > > > Now it passes on the previously failing freebsd systems (10 + > > > > > 11), > > > > > but > > > > > it fails now with freebsd 12 + 13. A sample report: > > > > > http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8-9416- > > > > > c1ac4f889b37 > > > > > > > > > > On 2018-12-05 22:05:57, BIGFOOT wrote:

> > > > > > Yes, that's the working theory - I've uploaded a new version > > > > > > 1.0.8 > > > > > > which I believe addresses the root cause - incorrect parsing > > > > > > of > > > > > > the > > > > > > ISO8601 date format using strptime(). Let's see how this one > > > > > > fares. > > > > > > > > > > > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > > > > > > Maybe it's timezone related? I just tried setting TZ=UTC > > > > > > > (originally > > > > > > > the freebsd10 system has Europe/Berlin configured), and now > > > > > > > the > > > > > > > tests > > > > > > > pass... > > > > > > > > > > > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > > > > > > Hmm..yes I saw that..puzzling as the test works on other > > > > > > > > versions > > > > > > > > and > > > > > > > > distros from what I can see in the test reports. The > > > > > > > > test > > > > > > > > attempts > > > > > > > > to > > > > > > > > determine if a token has timed out by looking at the > > > > > > > > token > > > > > > > > expiration > > > > > > > > time compared to the current time. I'll take a closer > > > > > > > > look > > > > > > > > at > > > > > > > > how > > > > > > > > my > > > > > > > > comparisons are being done and why it appears that it is > > > > > > > > busted > > > > > > > > only > > > > > > > > on versions > 5.20.0 and only on freebsd. > > > > > > > > > > > > > > > > Puzzling indeed. > > > > > > > > > > > > > > > > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > > > > > > On my freebsd10 and freebsd11 smokers t/02- > > > > > > > > > credentials.t > > > > > > > > > fails: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > # Failed test 'is_token_expired() - no?' > > > > > > > > > # at t/02-credentials.t line 72. > > > > > > > > > > > > > > > > > > # Failed test 'refresh_token()' > > > > > > > > > # at t/02-credentials.t line 94. > > > > > > > > > # Looks like you failed 2 tests of 6. > > > > > > > > > t/02-credentials.t .. > > > > > > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > > > > > > Failed 2/6 subtests > > > > > > > > > ...

Sun Dec 09 10:06:59 2018 BIGFOOT [...] cpan.org - Correspondence added

Thanks so much for your help and doing that bit of research! It would seem that a compliant ISO8601 time would have a standard way to parse it and my search of something standardized to parse this exact representation has not been successful (no doubt there is something though). I think this should do the trick: sub _iso8601_to_time { my $iso8601 = shift; $iso8601 =~s/^(.*)Z$/$1\+00:00/; return timegm(strptime($iso8601, "%FT%T%z")); } uploading a new version 1.0.9 . This has small requirement of converting and comparing expiration times has bitten me throughout writing this module. On Sat Dec 08 11:53:40 2018, SREZIC wrote: Show quoted text

> On 2018-12-08 11:03:07, SREZIC wrote:

> > On 2018-12-08 10:39:14, SREZIC wrote:

> > > On 2018-12-08 10:32:10, SREZIC wrote:

> > > > On 2018-12-06 11:38:52, BIGFOOT wrote:

> > > > > > Now it passes on the previously failing freebsd systems (10 + > > > > > > 11), > > > > > > but > > > > > > it fails now with freebsd 12 + 13. A sample report:

> > > > > > > > > > Wow, fun stuff. I'm not sure I necessarily believe that the > > > > > version > > > > > of freebsd 12/13 is the issue - but I do not have access to > > > > > those > > > > > distros at the moment. My inclination is that my test is bad? > > > > > > > > > > Oddly though the diagnostics tell me that the expiration date > > > > > and > > > > > current time are exactly 5 seconds apart (still exactly within > > > > > the > > > > > valid token time window) - which means that when > > > > > is_token_expired() > > > > > did the same conversions the time left should be 5s. If this > > > > > were > > > > > a > > > > > timing issue I would have expected the diagnostics to tell me > > > > > the > > > > > diff > > > > > between expiration time and current time was > 5 seconds. > > > > > > > > > > # $VAR1 = [ > > > > > # '2018-12-06T03:52:14Z', > > > > > # '2018-12-06T03:47:09Z' > > > > > # ]; > > > > > > > > > > > > > > > ...so almost certainly I must be seeing some drift from > > > > > timegm()? > > > > > > > > > > Any chance you can run this little snippet in those problem > > > > > envs? > > > > > > > > > > #!/usr/bin/perl > > > > > > > > > > use strict; > > > > > use warnings; > > > > > > > > > > use Time::Local; > > > > > use POSIX::strptime qw/strptime/; > > > > > use Date::Format; > > > > > > > > > > # notes: > > > > > # - expect UTC == GMT, EDT <> UTC > > > > > # - UTC is not really time zone, so maybe issue on some > > > > > platforms, > > > > > better to use GMT? > > > > > # - EDT should not be the same since my ISO8610 is Zulu > > > > > time...just > > > > > for sanity > > > > > > > > > > foreach my $tz (qw/UTC GMT EDT/) { > > > > > my $time = time; > > > > > my $iso8610 = time2str("%Y-%m-%dT%H:%M:%SZ", $time, $tz); > > > > > my $timegm = timegm(strptime($iso8610, "%Y-%m- > > > > > %dT%H:%M:%S%z")); > > > > > > > > > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n%s\n", $tz, > > > > > $iso8610, $time, $timegm, '-'x60); > > > > > } > > > > > > > > > > ...if not I will add some additional diagnostics and a debug > > > > > flag > > > > > for > > > > > testing

> > > > > > > > The test script surely returns something unexpected on freebsd 12 > > > > + > > > > 13: > > > > > > > > TZ: UTC ISO8601: 2018-12-08T15:30:26Z > > > > time: 1544283026 > > > > timegm: 976289426 > > > > ------------------------------------------------------------ > > > > TZ: GMT ISO8601: 2018-12-08T15:30:26Z > > > > time: 1544283026 > > > > timegm: 976289426 > > > > ------------------------------------------------------------ > > > > TZ: EDT ISO8601: 2018-12-08T11:30:26Z > > > > time: 1544283026 > > > > timegm: 976275026 > > > > ------------------------------------------------------------ > > > > > > > > > > > > It seems that the year field in the strptime output is broken. > > > > Here > > > > a > > > > working strptime on freebsd 11: > > > > > > > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", > > > > strptime("2018- > > > > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > > > > 10,10,10,10,11,118,6,341, at -e line 1. > > > > > > > > Here the bad output on freebsd 12: > > > > $ perl -MPOSIX::strptime=strptime -e 'warn join ",", > > > > strptime("2018- > > > > 12-10T10:10:10Z", "%Y-%m-%dT%H:%M:%S%z")' > > > > 10,10,10,10,11,,6,341, at -e line 1. > > > >

> > > > > > A FreeBSD bug? I tried a C program: > > > > > > #include <time.h> > > > #include <stdio.h> > > > > > > int main() { > > > struct tm tm; > > > printf("ret=%s\n", strptime("2018-12-10T10:10:10Z", "%Y-%m- > > > %dT%H:%M:%S%z", &tm)); > > > printf("year=%d\n", tm.tm_year); > > > } > > > > > > > > > Output on FreeBSD 11: > > > > > > ret=(null) > > > year=118 > > > > > > > > > Output on FreeBSD 12: > > > > > > ret=(null) > > > year=0 > > >

> > > > Well, reading the strptime and strftime manpages on linux & freebsd I > > am not sure that "Z" is supposed to be parsed by "%z". strptime > > returned NULL in the example c program in both cases, which indicates > > a parse error. It seems coincidence that the tm contents were already > > filled correctly on linux and freebsd <= 11. But in freebsd 12 and > > newer tm->tm_year is filled later (if I understand > > https://svnweb.freebsd.org/base/head/lib/libc/stdtime/strptime.c?view=markup&pathrev=340106 > > correctly), so here the year field is just left zero. > > > > What's probably safe is to use "+00:00" instead of "Z" here. > >

> > The CPAN module POSIX::2008 also provides a strptime function, and > this one just return undef for %z=Z. %z=+00:00 works: > > $ perl5.26.1 -MPOSIX::2008=strptime -e 'warn join(",", strptime("2018- > 10-10T12:34:45+00:00", "%Y-%m-%dT%H:%M:%S%z"))' > 45,34,12,10,9,118,3,282,-1 at -e line 1. > $ perl5.26.1 -MPOSIX::2008=strptime -e 'warn join(",", strptime("2018- > 10-10T12:34:45Z", "%Y-%m-%dT%H:%M:%S%z"))' > Warning: something's wrong at -e line 1. >

> > >

> > > > > > > > > > On Thu Dec 06 01:46:24 2018, SREZIC wrote:

> > > > > > Now it passes on the previously failing freebsd systems (10 + > > > > > > 11), > > > > > > but > > > > > > it fails now with freebsd 12 + 13. A sample report: > > > > > > http://www.cpantesters.org/cpan/report/9cf0f234-f921-11e8- > > > > > > 9416- > > > > > > c1ac4f889b37 > > > > > > > > > > > > On 2018-12-05 22:05:57, BIGFOOT wrote:

> > > > > > > Yes, that's the working theory - I've uploaded a new > > > > > > > version > > > > > > > 1.0.8 > > > > > > > which I believe addresses the root cause - incorrect > > > > > > > parsing > > > > > > > of > > > > > > > the > > > > > > > ISO8601 date format using strptime(). Let's see how this > > > > > > > one > > > > > > > fares. > > > > > > > > > > > > > > On Wed Dec 05 17:25:15 2018, SREZIC wrote:

> > > > > > > > Maybe it's timezone related? I just tried setting TZ=UTC > > > > > > > > (originally > > > > > > > > the freebsd10 system has Europe/Berlin configured), and > > > > > > > > now > > > > > > > > the > > > > > > > > tests > > > > > > > > pass... > > > > > > > > > > > > > > > > On 2018-12-05 16:29:34, BIGFOOT wrote:

> > > > > > > > > Hmm..yes I saw that..puzzling as the test works on > > > > > > > > > other > > > > > > > > > versions > > > > > > > > > and > > > > > > > > > distros from what I can see in the test reports. The > > > > > > > > > test > > > > > > > > > attempts > > > > > > > > > to > > > > > > > > > determine if a token has timed out by looking at the > > > > > > > > > token > > > > > > > > > expiration > > > > > > > > > time compared to the current time. I'll take a closer > > > > > > > > > look > > > > > > > > > at > > > > > > > > > how > > > > > > > > > my > > > > > > > > > comparisons are being done and why it appears that it > > > > > > > > > is > > > > > > > > > busted > > > > > > > > > only > > > > > > > > > on versions > 5.20.0 and only on freebsd. > > > > > > > > > > > > > > > > > > Puzzling indeed. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed Dec 05 16:20:02 2018, SREZIC wrote:

> > > > > > > > > > On my freebsd10 and freebsd11 smokers t/02- > > > > > > > > > > credentials.t > > > > > > > > > > fails: > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > # Failed test 'is_token_expired() - no?' > > > > > > > > > > # at t/02-credentials.t line 72. > > > > > > > > > > > > > > > > > > > > # Failed test 'refresh_token()' > > > > > > > > > > # at t/02-credentials.t line 94. > > > > > > > > > > # Looks like you failed 2 tests of 6. > > > > > > > > > > t/02-credentials.t .. > > > > > > > > > > Dubious, test returned 2 (wstat 512, 0x200) > > > > > > > > > > Failed 2/6 subtests > > > > > > > > > > ...

Mon Dec 10 11:20:44 2018 BIGFOOT [...] cpan.org - Correspondence added

Spun up a freebsd 13.0 server and installed 5.22.4 w/perlbrew... Looks to me like POSIX::strptime() is busted on that platform - revealed when TZ <> GMT...replacing with mktime() #!/usr/bin/env perl use strict; use warnings; use Time::Local; use POSIX::strptime qw/strptime/; use POSIX qw/mktime/; use Date::Format; # notes: # - expect UTC == GMT, EST <> UTC # - UTC is not really time zone, so maybe issue on some platforms, better to use GMT? # - EDT should not be the same since my ISO8610 is Zulu time...just for sanity foreach my $tz (qw/UTC GMT EST/) { my $time = time; my $iso8610 = time2str("%Y-%m-%dT%H:%M:%S+0000", $time, $tz); my ($sec, $min, $hour, $mday, $mon, $year) = strptime($iso8610, "%Y-%m-%dT%H:%M:%S%z"); printf("s:%s m:%s h:%s day:%s month:%s year:%s\n", $sec, $min, $hour, $mday, $mon, $year); my $mktime = mktime($sec, $min, $hour, $mday, $mon, $year); my $timegm = timegm($sec, $min, $hour, $mday, $mon, $year); printf("TZ: %s ISO8601: %s\ntime: %d\nmktime: %d\ntimegm: %d\n%s\n", $tz, $iso8610, $time, $mktime, $timegm, '-'x60); }

Mon Dec 10 11:22:40 2018 BIGFOOT [...] cpan.org - Correspondence added

...whoops meant to say timegm() is busted it appears

Mon Dec 10 11:22:41 2018 BIGFOOT [...] cpan.org - Fixed in 1.0.9 added

Mon Dec 10 11:22:41 2018 BIGFOOT [...] cpan.org - Fixed in 1.0.8 deleted

Mon Dec 10 13:41:56 2018 BIGFOOT [...] cpan.org - Correspondence added

strptime() in freebsd behaves differently than strptime() in linux. Consider the output from the script below (both run in a bash shell with TZ=America/New_York at nearly the same moment in time): #!/usr/bin/env perl use strict; use warnings; use Time::Local; use POSIX::strptime qw/strptime/; use Date::Format; my $tz = 'GMT'; my $time = time; my $iso8601 = time2str("%Y-%m-%dT%H:%M:%S $tz", $time, $tz); my @time_gm = strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); my $timegm = timegm(@time_gm); printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n", $tz, $iso8601, $time, $timegm); 8<----- freebsd ---- # ./strptime.pl TZ: GMT ISO8601: 2018-12-10T18:36:56 GMT time: 1544467016 timegm: 1544449016 8<----- linux ---- $ ./strptime.pl TZ: GMT ISO8601: 2018-12-10T18:36:54 GMT time: 1544467014 timegm: 1544467014 Conclusion: strptime() always returns time parsed as local time on freebsd 13.0 (at least), not sure of all variants.

Mon Dec 10 15:39:14 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-12-10 13:41:56, BIGFOOT wrote: Show quoted text

> strptime() in freebsd behaves differently than strptime() in linux. > Consider the output from the script below (both run in a bash shell > with TZ=America/New_York at nearly the same moment in time): > > #!/usr/bin/env perl > > use strict; > use warnings; > > use Time::Local; > use POSIX::strptime qw/strptime/; > use Date::Format; > > my $tz = 'GMT'; > my $time = time; > my $iso8601 = time2str("%Y-%m-%dT%H:%M:%S $tz", $time, $tz); > > my @time_gm = strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); > > my $timegm = timegm(@time_gm); > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n", $tz, $iso8601, > $time, $timegm); > > > 8<----- freebsd ---- > > # ./strptime.pl > TZ: GMT ISO8601: 2018-12-10T18:36:56 GMT > time: 1544467016 > timegm: 1544449016 > > 8<----- linux ---- > > $ ./strptime.pl > TZ: GMT ISO8601: 2018-12-10T18:36:54 GMT > time: 1544467014 > timegm: 1544467014 > > Conclusion: strptime() always returns time parsed as local time on > freebsd 13.0 (at least), not sure of all variants.

That's even documented in the strptime(3) manpage: The resulting values will be relative to the local time zone. And I checked down to freebsd 9: it was always this way. I wonder if it's better for you to switch to another module, maybe Time::Moment (or even DateTime). This would avoid all the problems with different OS strptime implementations.

Mon Dec 10 16:03:44 2018 BIGFOOT [...] cpan.org - Correspondence added

Yes, I noted that in the docs as well. So, one approach is to make sure local time is GMT. v1.0.10 does just that - I've localized %ENV and set it to GMT...tests passed on my 13.0/5.22.4 set up...however you may be correct that avoiding such O/S workarounds may be more prudent. On Mon Dec 10 15:39:14 2018, SREZIC wrote: Show quoted text

> On 2018-12-10 13:41:56, BIGFOOT wrote:

> > strptime() in freebsd behaves differently than strptime() in linux. > > Consider the output from the script below (both run in a bash shell > > with TZ=America/New_York at nearly the same moment in time): > > > > #!/usr/bin/env perl > > > > use strict; > > use warnings; > > > > use Time::Local; > > use POSIX::strptime qw/strptime/; > > use Date::Format; > > > > my $tz = 'GMT'; > > my $time = time; > > my $iso8601 = time2str("%Y-%m-%dT%H:%M:%S $tz", $time, $tz); > > > > my @time_gm = strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); > > > > my $timegm = timegm(@time_gm); > > > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n", $tz, $iso8601, > > $time, $timegm); > > > > > > 8<----- freebsd ---- > > > > # ./strptime.pl > > TZ: GMT ISO8601: 2018-12-10T18:36:56 GMT > > time: 1544467016 > > timegm: 1544449016 > > > > 8<----- linux ---- > > > > $ ./strptime.pl > > TZ: GMT ISO8601: 2018-12-10T18:36:54 GMT > > time: 1544467014 > > timegm: 1544467014 > > > > Conclusion: strptime() always returns time parsed as local time on > > freebsd 13.0 (at least), not sure of all variants.

> > That's even documented in the strptime(3) manpage: > > The resulting values will be relative to the local time zone. > > And I checked down to freebsd 9: it was always this way. > > I wonder if it's better for you to switch to another module, maybe > Time::Moment (or even DateTime). This would avoid all the problems > with different OS strptime implementations.

Mon Dec 10 17:25:07 2018 BIGFOOT [...] cpan.org - Correspondence added

...or as you suggest use a different module - perhaps there is a strptime() that is not ambiquous? Date::Parse::strptime()? I think the horse is officially dead. 8<-------- #!/usr/bin/env perl use strict; use warnings; use Time::Local; use Date::Format; use POSIX::strptime; use Date::Parse; my $tz = 'GMT'; my $time = time; my $iso8601 = time2str("%Y-%m-%dT%H:%M:%S $tz", $time, $tz); my @date_parse_time_gm = strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); my $date_parse_timegm = timegm(@date_parse_time_gm); my @posix_time_gm = POSIX::strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); my $timegm = timegm(@posix_time_gm); printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm(POSIX::strptime): %d\ntimegm(Date::Parse::strptime): %d\n", $tz, $iso8601, $time, $timegm, $date_parse_timegm); 8<-------- [root@freebsd ~]# echo $TZ ; date +'%Y-%m-%dT%H:%M:%S %Z'; ./strptime.pl America/Los_Angeles 2018-12-10T14:21:59 PST TZ: GMT ISO8601: 2018-12-10T22:21:59 GMT time: 1544480519 timegm(POSIX::strptime): 1544451719 timegm(Date::Parse::strptime): 1544480519 On Mon Dec 10 15:39:14 2018, SREZIC wrote: Show quoted text

> On 2018-12-10 13:41:56, BIGFOOT wrote:

Tue Dec 11 09:18:24 2018 BIGFOOT [...] cpan.org - Correspondence added

fixed in version 1.0.10

Tue Dec 11 09:18:25 2018 BIGFOOT [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Dec 11 09:18:25 2018 BIGFOOT [...] cpan.org - Fixed in 1.0.9 deleted

Tue Dec 11 15:26:46 2018 SREZIC [...] cpan.org - Correspondence added

On 2018-12-10 17:25:07, BIGFOOT wrote: Show quoted text

> ...or as you suggest use a different module - perhaps there is a > strptime() that is not ambiquous? Date::Parse::strptime()?

If it's just for parsing ISO8601 dates, then I would recommend Time::Moment->from_string. Show quoted text

> > I think the horse is officially dead. > > 8<-------- > #!/usr/bin/env perl > > use strict; > use warnings; > > use Time::Local; > use Date::Format; > use POSIX::strptime; > use Date::Parse; > > my $tz = 'GMT'; > my $time = time; > my $iso8601 = time2str("%Y-%m-%dT%H:%M:%S $tz", $time, $tz); > > my @date_parse_time_gm = strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); > my $date_parse_timegm = timegm(@date_parse_time_gm); > > my @posix_time_gm = POSIX::strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); > my $timegm = timegm(@posix_time_gm); > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm(POSIX::strptime): > %d\ntimegm(Date::Parse::strptime): %d\n", $tz, $iso8601, $time, > $timegm, $date_parse_timegm); > > 8<-------- > > [root@freebsd ~]# echo $TZ ; date +'%Y-%m-%dT%H:%M:%S %Z'; > ./strptime.pl > America/Los_Angeles > 2018-12-10T14:21:59 PST > TZ: GMT ISO8601: 2018-12-10T22:21:59 GMT > time: 1544480519 > timegm(POSIX::strptime): 1544451719 > timegm(Date::Parse::strptime): 1544480519 > > > > On Mon Dec 10 15:39:14 2018, SREZIC wrote:

> > On 2018-12-10 13:41:56, BIGFOOT wrote:

> > > strptime() in freebsd behaves differently than strptime() in linux. > > > Consider the output from the script below (both run in a bash shell > > > with TZ=America/New_York at nearly the same moment in time): > > > > > > #!/usr/bin/env perl > > > > > > use strict; > > > use warnings; > > > > > > use Time::Local; > > > use POSIX::strptime qw/strptime/; > > > use Date::Format; > > > > > > my $tz = 'GMT'; > > > my $time = time; > > > my $iso8601 = time2str("%Y-%m-%dT%H:%M:%S $tz", $time, $tz); > > > > > > my @time_gm = strptime($iso8601, "%Y-%m-%dT%H:%M:%S %Z"); > > > > > > my $timegm = timegm(@time_gm); > > > > > > printf("TZ: %s ISO8601: %s\ntime: %d\ntimegm: %d\n", $tz, $iso8601, > > > $time, $timegm); > > > > > > > > > 8<----- freebsd ---- > > > > > > # ./strptime.pl > > > TZ: GMT ISO8601: 2018-12-10T18:36:56 GMT > > > time: 1544467016 > > > timegm: 1544449016 > > > > > > 8<----- linux ---- > > > > > > $ ./strptime.pl > > > TZ: GMT ISO8601: 2018-12-10T18:36:54 GMT > > > time: 1544467014 > > > timegm: 1544467014 > > > > > > Conclusion: strptime() always returns time parsed as local time on > > > freebsd 13.0 (at least), not sure of all variants.

> > > > That's even documented in the strptime(3) manpage: > > > > The resulting values will be relative to the local time zone. > > > > And I checked down to freebsd 9: it was always this way. > > > > I wonder if it's better for you to switch to another module, maybe > > Time::Moment (or even DateTime). This would avoid all the problems > > with different OS strptime implementations.