On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote: > Time handling is not easy. I hate to say that, but POSIX and glibc > manage to make it even harder. Especially the timezone global handling > which is not thread-safe as you pinpointed. > Anyway, free conding a simple timegm() is not very hard, since you don't > have to take any timezone into account, only leap years.
That's what I've seen, none of them implement the leap seconds (I thought it was needed). > But beware that real timegm() (and mktime()) perform some time > normalization on tm_mday (day of the month) or tm_mon (month). > For example, they will happily work with fake dates like "March 31st > 2017", "February 59th 2017" or even "1st day of 18th month of 2016" and > will convert them to "April 1st 2017" internally. I've read this and apparently most of the time it's not needed at all. > It's very handy when you want to compute date in the future or in the > past, you just add/substract values to the corresponding field (day or > month) and let mktime() of timegm() do their magic trick. Yes, like you do with the "date" command to know what date it will be in 1 million seconds for example :-) Willy
