On 2020/04/15 5:33, Andrew Dunstan wrote:
>
> On 4/14/20 4:09 PM, Alvaro Herrera wrote:
>> On 2020-Apr-14, Andrew Dunstan wrote:
>>
>>> OK, but I think if we're putting a timestamp string in ISO-8601 format
>>> in the manifest it should be in UTC / Zulu time, precisely to avoid
>>> these issues. If that's too much trouble then yes an epoch time will
>>> probably do.
>> The timestamp is always specified and always UTC (except the code calls
>> it GMT).
>>
>> + /*
>> + * Convert last modification time to a string and append it to the
>> + * manifest. Since it's not clear what time zone to use and since time
>> + * zone definitions can change, possibly causing confusion, use GMT
>> + * always.
>> + */
>> + appendStringInfoString(&buf, "\"Last-Modified\": \"");
>> + enlargeStringInfo(&buf, 128);
>> + buf.len += pg_strftime(&buf.data[buf.len], 128, "%Y-%m-%d %H:%M:%S %Z",
>> + pg_gmtime(&mtime));
>> + appendStringInfoString(&buf, "\"");
>>
>> I was merely saying that it's trivial to make this iso-8601 compliant as
>>
>> buf.len += pg_strftime(&buf.data[buf.len], 128, "%Y-%m-%dT%H:%M:%SZ",
>>
>> ie. omit the "GMT" string and replace it with a literal Z, and remove
>> the space and replace it with a T.
I have one question related to this; Why don't we use log_timezone,
like backup_label? log_timezone is used for "START TIME" field in
backup_label. Sorry if this was already discussed.
/* Use the log timezone here, not the session timezone */
stamp_time = (pg_time_t) time(NULL);
pg_strftime(strfbuf, sizeof(strfbuf),
"%Y-%m-%d %H:%M:%S %Z",
pg_localtime(&stamp_time, log_timezone));
OTOH, *if* we want to use the same timezone for backup-related files because
backup can be used in different environements and timezone setting
may be different there or for other reasons, backup_label also should use
GMT or something for the sake of consistency?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION