> > hb_ctot( "2009-02-10 18:39:47 UTC+0100" ) => meaning 2009-02-10 18:39:47 >> UTC+0100 >> hb_ctot() could also accept all formats you wrote for t"": >> hb_ctot( "01:00" ) >> hb_ctot( "01:58:27" ) >> hb_ctot( "2009-02-09" ) >> > > Only runtime function evaluation (without compilers pseudo-function > optimisation) is possible, since hb_ctot() depends on > set(_SET_TIMESTAMPFORMAT, ...). Usage in libraries is not possible at all, > since library user can set any format.
Yes, that's why we need the 0h, 0t, hb_stot() flavours in the first place. It's yet to be thought out how can we, or is it possible at all to have a generic TIMEFORMAT to parse input strings, since there can be quite many variations, some ambiguous. I'd rather think that programs would mainly use ttos, stot when dealing with string / date conversions internally and resort to ttoc to produce human readable output, and ctot to parse human input, but even that only in rare cases. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
