Greg Brewer wrote:
>
> I've been quite pleased that my discussion topics have generated so many
> responses.  I thought I would take time to summarize.
>
> ...
>
> Part 5)  time function discussion -- actually posted in C forum
> Like NULL, I think there was a strong consensus that the current standard
> functions are inadequate.  All inadequacies identified dealt with timezones.
> It was noted that a big problem with the current implementations is that
> they assume US rules for daylight savings.  Adding new functions to handle
> time conversions will break no existing code.

Time zone problems are mostly quality of implementation issues. A good
implementation could deal with European time zone rules without changes
to the standard.

There is also an implicit dependence on the Gregorian calendar and
there probably should not be.

The time divisions should be part of the locale. I know it would be
complicated but a Chinese locale should invoke a Chinese year
structure. An Arabic locale would probably use the hegira as the
base year (sorry if I have this wrong, I just know that there is a
significant difference) and a B'ahi locale would make other changes.

All this gets VERY complicated, but time specification IS complicated
because so many different cultures are involved.

mtew@cds.duke.edu
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Max TenEyck Woodbury <mtew@cds.duke.edu> writes:

>Greg Brewer wrote:
>>
>> Part 5)  time function discussion -- actually posted in C forum
>> Like NULL, I think there was a strong consensus that the current standard
>> functions are inadequate.  All inadequacies identified dealt with timezones.
>> It was noted that a big problem with the current implementations is that
>> they assume US rules for daylight savings.  Adding new functions to handle
>> time conversions will break no existing code.

>Time zone problems are mostly quality of implementation issues. A good
>implementation could deal with European time zone rules without changes
>to the standard.

I'll go further. NOTHING in the standard assumes US rules for DST.
It doesn't require that DST apply to the current location (even in
the US, some places never go on DST).  The standard library
interface allows you only to inquire whether DST is in effect for
a given date and time.

A popular public-domain implementation of the <time.h> functions
takes into account not just the US and European rules, but Asian
time zones, and Southern Hemisphere rules (which of course have
reversed seasons), and half-hour time zones as well.  All the
variations are captured in tables that the functions search.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]