A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1797 
====================================================================== 
Reported By:                eggert
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1797
Category:                   System Interfaces
Type:                       Error
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Paul Eggert 
Organization:               UCLA Computer Science Dept. 
User Reference:             strftime-%s 
Section:                    strftime 
Page Number:                2136 
Line Number:                69836-69837 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-01-15 23:56 UTC
Last Modified:              2024-02-26 18:28 UTC
====================================================================== 
Summary:                    strftime "%s" should be able to examine tm_gmtoff
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0001533 struct tm: add tm_gmtoff (and tm_zone) ...
====================================================================== 

---------------------------------------------------------------------- 
 (0006688) eggert (reporter) - 2024-02-26 18:28
 https://austingroupbugs.net/view.php?id=1797#c6688 
---------------------------------------------------------------------- 
Unfortunately draft 4 for Issue 8 has significant problems here, and these
problems need to be fixed somehow. The draft does not tell users that
strftime %s might inspect tm_gmtoff - something that implementations other
than TZDB already do - and it is not entirely clear what the draft means by
values "outside the normal range" (line 69773 in draft 4) - for example, is
tm_day outside the normal range when it equals 30, and tm_mon happens to be
1?

We agree that applications that call gmtime and then strftime %s are broken
(unless localtime happens to be UTC). The desired action doesn't change
that. These apps will still not necessarily generate the output that the
app authors wanted.

The desired action does need improvement, along the lines of saying that
struct tm values are "in range" if they are values that localtime could
have set. Expect a revised proposal soon. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-01-15 23:56 eggert         New Issue                                    
2024-01-15 23:56 eggert         Name                      => Paul Eggert     
2024-01-15 23:56 eggert         Organization              => UCLA Computer
Science Dept.
2024-01-15 23:56 eggert         User Reference            => strftime-%s     
2024-01-15 23:56 eggert         Section                   => strftime        
2024-01-15 23:56 eggert         Page Number               => 2136            
2024-01-15 23:56 eggert         Line Number               => 69836-69837     
2024-01-16 01:29 steffen        Note Added: 0006623                          
2024-01-16 01:42 steffen        Note Added: 0006624                          
2024-01-16 01:42 steffen        Note Deleted: 0006623                        
2024-02-01 16:42 nick           Relationship added       related to 0001533  
2024-02-12 16:11 eblake         Note Added: 0006651                          
2024-02-25 06:50 kre            Note Added: 0006677                          
2024-02-25 06:54 kre            Note Edited: 0006677                         
2024-02-26 18:28 eggert         Note Added: 0006688                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Steffen Nurpmeso via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
          • ... Steffen Nurpmeso via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to