F29 System Wide Change: The tzdata transition to 'vanguard' format

[Jan Kurik]

= Proposed System Wide Change: The tzdata transition to 'vanguard' format =
https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD


Owner(s):
  * Patsy Franklin <pfrankli at redhat dot com>


As of tzdata-2018e, the upstream will now default to using the
'vanguard' data format including negative DST offsets.  As a
fall-back, the 'rearguard' data format is still available on F28, F27
and F26.



== Detailed description ==
tzdata-2018e defaults to the 'vanguard' data format.  This format
includes the POSIX compliant implementations of negative DST offsets
which have been an issue for both Java and ICU parsers. We plan to
transition to this default format in F29.


== Scope ==
* Proposal owners:
Implement the proposal.

* Other developers:
Developers need to ensure that their packages are able to correctly
parse and/or build with the new tzdata 'vanguard' format.

* Release engineering:
The tzdata maintainer will ensure that the package builds and passes
all tests on F29.
RelEng ticket: https://pagure.io/releng/issue/7510 #7510

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
Not needed for this change
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 22, 2018 at 04:24:05PM +0200, Jan Kurik wrote:
>  = Proposed System Wide Change: The tzdata transition to
> 'vanguard' format =
>  https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD 
Hi,

does the new format change the magic at the beginning of the file?
In systemd upstream we recently added a verification step that checks
that timezone files set with 'timedatectl set-timezone ...' have the right
signature [1]. If it changes, we'll have to adjust that commit.

[1] https://github.com/systemd/systemd/commit/a2932d5116

Zbyszek

[Patsy Franklin]

Hi,

Thanks for the question!  No, this change should not change the signature
at the beginning of the file.  My understanding is that it should only
impact application provided parsers that read the time zone data files and
expect the SAVE/DST values to only be positive.

Thanks,
Patsy

On Tue, May 22, 2018 at 10:49 AM, Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; wrote:

>  On Tue, May 22, 2018 at 04:24:05PM +0200, Jan Kurik wrote:
>  > = Proposed System Wide Change: The tzdata transition to 'vanguard'
>  format =
>  > https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD
>
>  Hi,
>
>  does the new format change the magic at the beginning of the file?
>  In systemd upstream we recently added a verification step that checks
>  that timezone files set with 'timedatectl set-timezone ...' have the right
>  signature [1]. If it changes, we'll have to adjust that commit.
>
>  [1] https://github.com/systemd/systemd/commit/a2932d5116
>
>  Zbyszek
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
>  fedoraproject.org/message/MPOHX3B6URSIC6XHNX5BUTCPAC6QUBOX/
>

[Lennart Poettering]

On Di, 22.05.18 16:24, Jan Kurik (jkurik(a)redhat.com) wrote:

>  = Proposed System Wide Change: The tzdata transition to
> 'vanguard' format =
>  https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD
>  
>  
>  Owner(s):
>    * Patsy Franklin <pfrankli at redhat dot com>
>  
>  
>  As of tzdata-2018e, the upstream will now default to using the
>  'vanguard' data format including negative DST offsets.  As a
>  fall-back, the 'rearguard' data format is still available on F28, F27
>  and F26. 
The old format was nicely documented in tzfile(5):

http://man7.org/linux/man-pages/man5/tzfile.5.html

Through this it kinda has become API. Which doesn't mean it can't be
changed, but can we please make sure that the new format is as well
documented as the old one, i.e. please update that man page along with
this new feature.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat

[Florian Weimer]

On 05/22/2018 05:06 PM, Lennart Poettering wrote:
>  The old format was nicely documented in tzfile(5):
>  
>  http://man7.org/linux/man-pages/man5/tzfile.5.html
>  
>  Through this it kinda has become API. Which doesn't mean it can't be
>  changed, but can we please make sure that the new format is as well
>  documented as the old one, i.e. please update that man page along with
>  this new feature. 
My understanding is that the format (as documented) hasn't actually 
changed, but the data provided in the tzdata package now contains 
negative DST offsets for the first time, something that certain 
implementations are not prepared to deal with.

Thanks,
Florian

[Patsy Franklin]

On Wed, May 23, 2018 at 3:23 AM, Florian Weimer <fweimer(a)redhat.com&gt; wrote:

>  On 05/22/2018 05:06 PM, Lennart Poettering wrote:
>
> > The old format was nicely documented in tzfile(5):
> >
> > http://man7.org/linux/man-pages/man5/tzfile.5.html
> >
> > Through this it kinda has become API. Which doesn't mean it can't be
> > changed, but can we please make sure that the new format is as well
> > documented as the old one, i.e. please update that man page along with
> > this new feature.
> >
>
>  My understanding is that the format (as documented) hasn't actually
>  changed, but the data provided in the tzdata package now contains negative
>  DST offsets for the first time, something that certain implementations are
>  not prepared to deal with.
>
>  
Correct!  Thanks for clarifying this Florian!

[Patsy Franklin]

Hi,

I agree that the documentation has been very good. From what I've seen,
the upstream maintainer continues to update the documentation as needed.

Thanks for your input!
Patsy

On Tue, May 22, 2018 at 11:06 AM, Lennart Poettering <mzerqung(a)0pointer.de&gt;
wrote:

>  On Di, 22.05.18 16:24, Jan Kurik (jkurik(a)redhat.com) wrote:
>
>  > = Proposed System Wide Change: The tzdata transition to 'vanguard'
>  format =
>  > https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD
>  >
>  >
>  > Owner(s):
>  >   * Patsy Franklin <pfrankli at redhat dot com>
>  >
>  >
>  > As of tzdata-2018e, the upstream will now default to using the
>  > 'vanguard' data format including negative DST offsets.  As a
>  > fall-back, the 'rearguard' data format is still available on F28, F27
>  > and F26.
>
>  The old format was nicely documented in tzfile(5):
>
>  http://man7.org/linux/man-pages/man5/tzfile.5.html
>
>  Through this it kinda has become API. Which doesn't mean it can't be
>  changed, but can we please make sure that the new format is as well
>  documented as the old one, i.e. please update that man page along with
>  this new feature.
>
>  Thanks,
>
>  Lennart
>
>  --
>  Lennart Poettering, Red Hat
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
>  fedoraproject.org/message/GV4ECQVF6LBBIWMS6J5RAQ5SBIX6JWRT/
>

[Vít Ondruch]

Is this going to be backward compatible or not? rubygem-tzinfo is using
tzdata as data source, so I wonder if any action is required.


V.


Dne 22.5.2018 v 16:24 Jan Kurik napsal(a):
>  = Proposed System Wide Change: The tzdata transition to
> 'vanguard' format =
>  https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD
>
>
>  Owner(s):
>    * Patsy Franklin <pfrankli at redhat dot com>
>
>
>  As of tzdata-2018e, the upstream will now default to using the
>  'vanguard' data format including negative DST offsets.  As a
>  fall-back, the 'rearguard' data format is still available on F28, F27
>  and F26.
>
>
>
>  == Detailed description ==
>  tzdata-2018e defaults to the 'vanguard' data format.  This format
>  includes the POSIX compliant implementations of negative DST offsets
>  which have been an issue for both Java and ICU parsers. We plan to
>  transition to this default format in F29.
>
>
>  == Scope ==
>  * Proposal owners:
>  Implement the proposal.
>
>  * Other developers:
>  Developers need to ensure that their packages are able to correctly
>  parse and/or build with the new tzdata 'vanguard' format.
>
>  * Release engineering:
>  The tzdata maintainer will ensure that the package builds and passes
>  all tests on F29.
>  RelEng ticket: https://pagure.io/releng/issue/7510 #7510
>
>  * Policies and guidelines:
>  The policies and guidelines do not need to be updated.
>
>  * Trademark approval:
>  Not needed for this change

[Patsy Franklin]

Hi,

Thank you for your input on this!

The concern is that, in some cases, applications that parse the tzdata
files were not expecting to find negative DST offsets (negative SAVE values
in the data files) despite the fact that POSIX appears to support this.

As this is now the default format for tzdata,  these applications should be
fixed to recognize the negative DST offsets.

(NOTE: For f26, f27 and f28, we have provided the rearguard format to
continue to support existing applications.  This proposal announces the
transition to vanguard format, allowing time to update applications in f29.)

On Wed, May 23, 2018 at 4:51 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:

>  Is this going to be backward compatible or not? rubygem-tzinfo is
> using
>  tzdata as data source, so I wonder if any action is required.
>
>  
Yes, it's backward compatible if your application recognizes that tzdata
SAVE values/DST's can be negative.

Thanks,
Patsy

[Vít Ondruch]

Thx for the answer. I opened upstream ticket to doublecheck this:

https://github.com/tzinfo/tzinfo/issues/88


V.


Dne 24.5.2018 v 19:32 Patsy Franklin napsal(a):
>  Hi,
>
>  Thank you for your input on this!
>
>  The concern is that, in some cases, applications that parse the tzdata
>  files were not expecting to find negative DST offsets (negative SAVE
>  values in the data files) despite the fact that POSIX appears to
>  support this. 
>
>  As this is now the default format for tzdata,  these applications
>  should be fixed to recognize the negative DST offsets.
>
>  (NOTE: For f26, f27 and f28, we have provided the rearguard format to
>  continue to support existing applications.  This proposal announces
>  the transition to vanguard format, allowing time to update
>  applications in f29.)
>
>  On Wed, May 23, 2018 at 4:51 AM, Vít Ondruch <vondruch(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>
>      Is this going to be backward compatible or not? rubygem-tzinfo is
>      using
>      tzdata as data source, so I wonder if any action is required.
>
>
>  Yes, it's backward compatible if your application recognizes that
>  tzdata SAVE values/DST's can be negative. 
>   
>  Thanks,
>  Patsy
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail].o...

[Vít Ondruch]

Just FTR, this is upstream response:


>  Yes, tzinfo supports the vanguard format introduced in tzdata 2018d
that became the main format in 2018e.

>  Conversions to and from local time will be accurate with any release
supporting system zoneinfo files.

>  I would recommend using the latest v1.2.5
<https://github.com/tzinfo/tzinfo/releases/tag/v1.2.5> release though.
This includes a fix to allow negative daylight savings time offsets to
be derived from zoneinfo files. This sets the
|TimezonePeriod#std_offset|
<https://www.rubydoc.info/gems/tzinfo/1.2.5/TZInfo/TimezonePeriod#std_offs...
and |TimezonePeriod#utc_offset|
<https://www.rubydoc.info/gems/tzinfo/1.2.5/TZInfo/TimezonePeriod#utc_offs...
attributes correctly when loading zoneinfo time zones that contain
negative DST offsets.


TL;DR rubygem-tzinfo should be compatible with the new tzdata, but I
should probably update to the latest version.


Vít



Dne 25.5.2018 v 10:29 Vít Ondruch napsal(a):
>  Thx for the answer. I opened upstream ticket to doublecheck this:
>
>  https://github.com/tzinfo/tzinfo/issues/88
>
>
>  V.
>
>
>  Dne 24.5.2018 v 19:32 Patsy Franklin napsal(a):
> > Hi,
> >
> > Thank you for your input on this!
> >
> > The concern is that, in some cases, applications that parse the
> > tzdata files were not expecting to find negative DST offsets
> > (negative SAVE values in the data files) despite the fact that POSIX
> > appears to support this. 
> >
> > As this is now the default format for tzdata,  these applications
> > should be fixed to recognize the negative DST offsets.
> >
> > (NOTE: For f26, f27 and f28, we have provided the rearguard format to
> > continue to support existing applications.  This proposal announces
> > the transition to vanguard format, allowing time to update
> > applications in f29.)
> >
> > On Wed, May 23, 2018 at 4:51 AM, Vít Ondruch <vondruch(a)redhat.com
> > <mailto:[e-mail]>> wrote:
> >
> >     Is this going to be backward compatible or not? rubygem-tzinfo is
> >     using
> >     tzdata as data source, so I wonder if any action is required.
> >
> >
> > Yes, it's backward compatible if your application recognizes that
> > tzdata SAVE values/DST's can be negative. 
> >  
> > Thanks,
> > Patsy
> >
> >
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail].o...