Hello everyone, I'm working on a TZDB parser for a PHP project and reading the zic8.txt I came across with the following information: The month, day, and time of day have the same format as the IN, ON, and AT
fields of a rule
However, I could not find any Zone line in the latest version of the TZDB containing relative dates, such as "lastSun" or "sun>=5", but only absolute dates. Is this a mistake in the documentation or are relative dates actually supported on those lines but have never been used? - Marcos
On Wed, 28 Nov 2018, Marcos Passos wrote:
I'm working on a TZDB parser for a PHP project
Why? PHP has the TZDB built in: http://uk3.php.net/datetimezone Including access to all transitions: http://uk3.php.net/manual/en/datetimezone.gettransitions.php cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug
Hi Derick, We know that, but we have some specific requirement the current API does not fulfill. Thank you for bringing it up anyway. Just out of curiosity, does timelib internally handle the possibility of relative dates on Zone lines? Regards, Marcos On Thu, Nov 29, 2018 at 06:53 Derick Rethans <tz@derickrethans.nl> wrote:
On Wed, 28 Nov 2018, Marcos Passos wrote:
I'm working on a TZDB parser for a PHP project
Why?
PHP has the TZDB built in: http://uk3.php.net/datetimezone
Including access to all transitions: http://uk3.php.net/manual/en/datetimezone.gettransitions.php
cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug
On 29/11/2018 10:22, Marcos Passos wrote:
We know that, but we have some specific requirement the current API does not fulfill. Thank you for bringing it up anyway.
It would be useful to know just what? My own problem is the unreliability of the inclusion of the backzone data and the poor support for tracking the version of TZ data being used. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
In addition to the issues you already mentioned: - Fetching data from different TZDB releases for auditing purposes - Lack of an API that provides a fast way to find gaps and overlaps for disambiguation purposes Em qui, 29 de nov de 2018 às 09:00, Lester Caine <lester@lsces.co.uk> escreveu:
On 29/11/2018 10:22, Marcos Passos wrote:
We know that, but we have some specific requirement the current API does not fulfill. Thank you for bringing it up anyway.
It would be useful to know just what? My own problem is the unreliability of the inclusion of the backzone data and the poor support for tracking the version of TZ data being used.
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On 29/11/2018 11:08, Marcos Passos wrote:
In addition to the issues you already mentioned:
- Fetching data from different TZDB releases for auditing purposes That one is not just for auditing ... it is essential to unwind historic data that was normalized using an older version! We do need a full working tzdist service of some sort?
- Lack of an API that provides a fast way to find gaps and overlaps for disambiguation purposes
Em qui, 29 de nov de 2018 às 09:00, Lester Caine <lester@lsces.co.uk <mailto:lester@lsces.co.uk>> escreveu:
On 29/11/2018 10:22, Marcos Passos wrote: > We know that, but we have some specific requirement the current API does > not fulfill. Thank you for bringing it up anyway.
It would be useful to know just what? My own problem is the unreliability of the inclusion of the backzone data and the poor support for tracking the version of TZ data being used.
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
For the record, I found some zones that uses it: Zone Asia/Baku 3:00 RussiaAsia +03/+04 1992 Sep lastSun 2:00s - Marcos Em qui, 29 de nov de 2018 às 09:08, Marcos Passos < marcospassos.com@gmail.com> escreveu:
In addition to the issues you already mentioned:
- Fetching data from different TZDB releases for auditing purposes - Lack of an API that provides a fast way to find gaps and overlaps for disambiguation purposes
Em qui, 29 de nov de 2018 às 09:00, Lester Caine <lester@lsces.co.uk> escreveu:
On 29/11/2018 10:22, Marcos Passos wrote:
We know that, but we have some specific requirement the current API does not fulfill. Thank you for bringing it up anyway.
It would be useful to know just what? My own problem is the unreliability of the inclusion of the backzone data and the poor support for tracking the version of TZ data being used.
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
participants (3)
-
Derick Rethans -
Lester Caine -
Marcos Passos