Re^2: epoch reduction

I like this solution.

However, my suggestion would be to use gmtime instead of localtime and use the same algorithm. But that of course depends upon what the OP is really trying to do. I didn't see anything in the problem statement about local time. Epoch time is a monotonically increasing number of seconds from an arbitrary start time. Weird things can happen when translating UTC (GMT) based time back into a local time.

For a wild example: Samoa changes Date/Time Line. Smaller versions of this happens when we change between Summer and Winter time.

Comment on Re^2: epoch reduction

Replies are listed 'Best First'.
Re^3: epoch reduction by ikegami (Patriarch) on Apr 20, 2012 at 16:36 UTC
I didn't see anything in the problem statement about local time I do not consider "sometimes 8pm to 8pm and sometimes 7pm to 7pm" to be the default definition of "day". I would have thought that if someone says today without qualification, that means midnight to midnight where he is observing. Even if every day is not the same length. I don't know why you're assuming he wants the date somewhere else in the world. But yes, any time zone's day could be used by the solution I posted.	[reply]
Re^4: epoch reduction by Marshall (Canon) on Apr 22, 2012 at 08:06 UTC
Almost all of the log files I work with are in UTC (GMT) and from multiple time zones. So the question of "what means a new day" can be relevant. If the OP's system is just single time zone and doesn't have to deal with this maybe +10 hour or whatever difference, OK. I did like your solution, the minor quibble is about time zone stuff.	[reply]