[Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)

pavlinamv notifications at github.com
Fri Aug 2 05:56:33 UTC 2019

Thank you for the observation. You are correct, command:
```$ date --date='Wed 31 Jul 2019 09:02:40 AM UTC' +'%s'```
is doing exactly the 'rpm task' (described in my previous comment).

I tried to test this functionality using some short-cuts. With the results:
* command `date` recognizes the short-cut and do the task correctly for some timezones e.g. A, AKDT, ...

* command `date` does not recognize the short-cut and writes an error. E. g. ACST, ACT, ...

* one short-cut denotes two (or more) timezones. E.g GST can be short-cut for even four time zones [2]. Command `date` chooses one of them and computes the time for the chosen time zone. Similarly for ADT and AST, ....

A little bit of statistics. I tested  time zone short-cuts with names starting by A-E (using [1]). The number of time zones was 70. The mentioned version of `date` command correctly resolved 14 of them, `date` did not recognise 51 of them and  5 were resolved as one of more possible time zones. So this approach is not much reliable for us.

Moreover, I checked the underlying source code for resolving of the mentioned version of `date` commands. It uses 3 data structures (`time_zone_table`, `universal_time_zone_table`, `military_table`) contained in `lib/parse-datetime.c`. Comment before the most interesting of the tables (`time_zone_table`) says:
/* The time zone table.  This table is necessarily incomplete, as time
zone abbreviations are ambiguous; e.g. Australians interpret "EST"
as Eastern time in Australia, not as US Eastern Standard Time.
You cannot rely on parse_datetime to handle arbitrary time zone
abbreviations; use numeric abbreviations like "-0500" instead.  */

Thus I think that this solution is not suitable to be used in rpm.

[1] https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
[2] https://www.worldtimezone.com/wtz-names/wtz-gst.html

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20190801/69ad0750/attachment-0001.html>

More information about the Rpm-maint mailing list