ctime library - is there anything better in c++?

Is the ctime library really that poorly designed, or is it just me
looking to do things the wrong way?
>
The whole concept of the struct tm seems way too highlevel for my taste
- this is something that I would implement myself if needed.
>
I have started programming c++ long before I did Visual Basic, and even
before Visual Basic was around. However, one has to give credit, where
credit is due: What's wrong with the (imo really good) VB approach to
store dates as a floating point value with the whole numbers being the
days since day X and the fraction being the part of the day elapsed?
I.e. 0.5 = 12:00 hours, 1/24 = 1 hour and so on?
>
If I need any more accurate times, I'll use the timer that starts when
the computer is turned on, not the system clock!
>
Then the tm structs definitions:http://www.cplusplus.com/reference/c.../ctime/tm.html
All the values are seconds, minutes, hours, days, months *SINCE* some
point in time, starting with 0, but the tm_mday all of a sudden is "day
of the month" (values 1-31). What ever happened to consistency?
>
Now if I want to do such a simple thing as read a users text input of a
year and a "day of year", and convert it to an ISO date, I
first: have to create & initialize a tm struct with the date tm_year =
userInput, tm_month = 0, tm_mday = 1, then
second: have to convert that into a time_t value, using mktime()
function that also manipulates my input(!) value,
third: add the user entered "day of year" (minus one) to the time_t,
multiplied by 86400 seconds in a day of course, and finally
fourth: convert the time_t back to a tm struct so I am able to output it
for the user
>
Not to mention that the tm struct should be a class and initialize in
the constructor with the calendar's counting start date, instead of all
random values (or at least, if it isn't done for speed reasons, an
initialize routine should be part of the library - it's a one-liner, but
it's annoying to do it yourself as a user and include a function that
should be part of the library in every single program that needs it).
>
Then why on earth does the strftime function take a struct tm as an
argument, and not the (much more sensible) time_t format?
>
In my eyes, the ctime library is really the poorest piece of programming
I have ever seen in an official c standard library. The only reason I'm
forced to use it at the moment is that I do not know how to reliably
calculate leap years, leap seconds and the likes and really do not feel
like creating my own date/time library at all. Not to mention If I did
it, it wouldn't be anywhere near the speed performance that the standard
library probably is.
>
So - after being done with my rant, can someone point me to a better
solution in C++?
>
Best Regards,
>
Lars
>
PS: What were they thinking???

Use boost library. It is open source. Download it from
www.boost.org

What's wrong with the (imo really good) VB approach to
store dates as a floating point value with the whole numbers being the
days since day X and the fraction being the part of the day elapsed?

>Is the ctime library really that poorly designed, or is it just me
>looking to do things the wrong way?
>
>The whole concept of the struct tm seems way too highlevel for my taste
>- this is something that I would implement myself if needed.
>
>I have started programming c++ long before I did Visual Basic, and even
>before Visual Basic was around. However, one has to give credit, where
>credit is due: What's wrong with the (imo really good) VB approach to
>store dates as a floating point value with the whole numbers being the
>days since day X and the fraction being the part of the day elapsed?
>I.e. 0.5 = 12:00 hours, 1/24 = 1 hour and so on?

>If I need any more accurate times, I'll use the timer that starts when
>the computer is turned on, not the system clock!
>
>Then the tm structs definitions:
>http://www.cplusplus.com/reference/c.../ctime/tm.html
>All the values are seconds, minutes, hours, days, months *SINCE* some
>point in time, starting with 0, but the tm_mday all of a sudden is "day
>of the month" (values 1-31). What ever happened to consistency?

>Now if I want to do such a simple thing as read a users text input of a
>year and a "day of year", and convert it to an ISO date, I
>first: have to create & initialize a tm struct with the date tm_year =
>userInput, tm_month = 0, tm_mday = 1, then
>second: have to convert that into a time_t value, using mktime()
>function that also manipulates my input(!) value,
>third: add the user entered "day of year" (minus one) to the time_t,
>multiplied by 86400 seconds in a day of course, and finally
>fourth: convert the time_t back to a tm struct so I am able to output it
>for the user

>
Accuracy comes to mind. For example the value 0.1 cannot be
represented accurately with base-2 floating point numbers (for the exact
same reason as 1/3 cannot be represented accurately with base-10 decimal
numbers).

Sounds poor to me...

>
Euh, ask the peoples that invented the time system. In most cultures
I have been exposed to, a day starts at 00:00:00 as hours, minutes
and seconds (some use 12:00:00 AM but most understand both). Nowhere
that I am aware start their day at 01:01:01.

So the C library when creating a human referenceable structure simply
followed accepted human patterns.

Sounds convoluted to me. Don't you have strptime?
http://www.opengroup.org/onlinepubs/.../strptime.html

Lars Uffmann wrote:

Accuracy comes to mind. For example the value 0.1 cannot be
represented accurately with base-2 floating point numbers (for
the exact same reason as 1/3 cannot be represented accurately
with base-10 decimal numbers).

If you add 0.1 to itself 10 times, you won't get 1.0 (you get
a value which is extremely close to it, but not exactly 1.0).
That might not be what one wants.

Yannick Tremblay wrote:

YMMD - it makes for very easy date calculation when you have
to handle lots and lots of date routines (where speed isn't as
big an issue as variety).

Well - then why is the ctime implementation of struct tm also
counting months starting from zero? And the weekday (tm_wday),

day of year (tm_yday) as well as the year (ok, actually that
is being counted from 1970

- also a big limitation of this time format: due to the
unnecessarily high accuracy, you can not express any dates
prior to 1902-01-01...

Not really ;)

No, I was not aware of it, but that was the purpose of my OP -
I wanted to learn about alternatives :) So thanks for that!

Is the ctime library really that poorly designed, or is it just me looking
to do things the wrong way?