A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1533 
====================================================================== 
Reported By:                steffen
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1533
Category:                   Base Definitions and Headers
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       steffen 
Organization:                
User Reference:              
Section:                    time.h 
Page Number:                425 
Line Number:                14451 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2021-11-08 22:04 UTC
Last Modified:              2022-02-06 23:28 UTC
====================================================================== 
Summary:                    struct tm: add tm_gmtoff (and tm_zone) field(s)
====================================================================== 

---------------------------------------------------------------------- 
 (0005667) kre (reporter) - 2022-02-06 23:28
 https://austingroupbugs.net/view.php?id=1533#c5667 
---------------------------------------------------------------------- 
Re https://austingroupbugs.net/view.php?id=1533#c5664

Yes, Anyone who got to define their struct tm late enough in time could
have made tm_year wider (not sure I would have picked time_t though - it
certainly guarantees that tm_year can represent any year that a time_t can
represent, but it makes tm dependent upon the time_t type, and since the
former ie very very difficult to ever change, it kind of locks you into a
specific time_t as well).

And Re https://austingroupbugs.net/view.php?id=1533#c5660

Whether sub-second precision is useful or not all depends upon the
application, when used for things like syslog message logging (anything
similar) sub-second precision is almost a requirement.  Further, it is
possible today, just ugly, one just uses strftime() with a format that
ends with "%S", then sprintf(".%u") as appropriate to get the sub-second
precisiion needed, and then if needed, another strftime() to get anything
that is needed after the time.   It is just ugly.

Making that data available in a struct tm replacement would make all of
this
much simpler,   It was never there originally only because back when tm
was
designed there was no way to access the time more accurately than seconds
(the time() sys call - gettimeofday() etc didn't yet exist). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2021-11-08 22:04 steffen        New Issue                                    
2021-11-08 22:04 steffen        Name                      => steffen         
2021-11-08 22:04 steffen        Section                   => time.h          
2021-11-08 22:04 steffen        Page Number               => 425             
2021-11-08 22:04 steffen        Line Number               => 14451           
2021-11-21 22:28 steffen        Note Added: 0005529                          
2021-11-22 09:47 geoffclare     Note Added: 0005530                          
2021-11-22 10:12 geoffclare     Note Added: 0005531                          
2021-11-22 10:50 geoffclare     Note Added: 0005532                          
2021-11-22 15:26 steffen        Note Added: 0005533                          
2021-11-22 15:36 steffen        Note Added: 0005534                          
2022-02-03 16:58 shware_systems Note Added: 0005656                          
2022-02-03 17:32 Don Cragun     Note Added: 0005657                          
2022-02-03 18:41 kre            Note Added: 0005658                          
2022-02-03 22:18 steffen        Note Added: 0005660                          
2022-02-06 11:37 mirabilos      Note Added: 0005664                          
2022-02-06 23:28 kre            Note Added: 0005667                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Steffen Nurpmeso via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to