Thank you for your review again.
> ...but I think Timestamp[Tz]s are stored as microseconds, so we're off
> by a factor of a million. This still works because later we cast to
> double and pass it back through float8_timestamptz, which converts it:
In my test, if I made ASN1_TIME_to_timestamptz to return in microseconds, the
float8_timestamptz() function will catch a "timestamp out of range" exception as
this function treats the input as seconds.
> But anyone who ends up inspecting the value of
> st_sslstatus->ssl_not_before directly is going to find an incorrect
> timestamp. I think it'd be clearer to store microseconds to begin
> with, and then just use TimestampTzGetDatum rather than the
> DirectFunctionCall1 we have now.
I have also tried TimestampTzGetDatum with ASN1_TIME_to_timestamptz
outputting in microseconds. No exception is caught, but pg_stat_ssl displays
incorrect results. The timestamps are extra large because the extra factor of
1 million is considered in the timestamp computation as well.
The comments for TimestampTz says:
* Timestamps, as well as the h/m/s fields of intervals, are stored as
* int64 values with units of microseconds. (Once upon a time they were
* double values with units of seconds.)
but it seems to me that many of the timestamp related functions still consider
timestamp or timestampTz as "double values with units of seconds" though.
Best regards
Cary Huang
-------------
HighGo Software Inc. (Canada)
cary.huang@highgo.ca
www.highgo.ca