Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
Date: 2023-09-19 19:40:46
Message-ID: 20f76b64-c572-7320-64cc-2f6fb3548552@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/19/23 18:45, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> I have no experience with tcl, but I tried this in the two tclsh
>> versions installed no the system (8.6 and 8.7):
>
>> bsd(at)freebsd:~ $ tclsh8.7
>> % clock scan "1/26/2010"
>> time value too large/small to represent
>
>> bsd(at)freebsd:~ $ tclsh8.6
>> % clock scan "1/26/2010"
>> time value too large/small to represent
>
>> AFAIK this is what the tcl_date_week(2010,1,26) translates to.
>
> Oh, interesting. On my FreeBSD 13.1 arm64 system, it works:
>
> $ tclsh8.6
> % clock scan "1/26/2010"
> 1264482000
>
> I am now suspicious that there's some locale effect that we have
> not observed before (though why not?). What is the result of
> the "locale" command on your box? Mine gives
>
> $ locale
> LANG=C.UTF-8
> LC_CTYPE="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_ALL=
>

bsd(at)freebsd:~ $ locale
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

bsd(at)freebsd:~ $ tclsh8.6
% clock scan "1/26/2010"
time value too large/small to represent

However, I wonder if there's something wrong with tcl itself,
considering this:

% clock format 1360558800 -format %D
02/11/2013
% clock scan 02/11/2013 -format %D
time value too large/small to represent

That's a bit strange - it seems tcl can format a timestamp, but then
can't read it back in for some reason ...

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-09-19 20:48:52 Re: Improving btree performance through specializing by key shape, take 2
Previous Message Andres Freund 2023-09-19 18:55:40 Re: Disabling Heap-Only Tuples