# mktime()

Steven Abner pheonix@zoomtown.com
Wed Oct 12 09:59:00 GMT 2011

```On Oct 11, 2011, at 7:29 AM, Corinna Vinschen wrote:

You all are going to love this one, get the aspirin out!

PLEASE: review the test thoroughly before any alterations, decisions or hanging of the author.

This issue I dubbed "double daylight". The program(test) is my best attempt to display. I had to make semi-large, as possible solutions can allow one to pass a test, but not all of them.

If you recall, I sent that big honkin' patch before to get newlib up for my testing. This is because newlib has a different definition of time then I have. And apparently nih code has a different definition then both of us. This means that the solution I am suggesting is not the only answer.
Repeating again, to avoid the whipping post, not the only answer, nor does it mean this is a newlib problem!
This is an issue for your review and decision.

The idea behind the test is to show those differences.
Do not take the following as gospel, but a premise, a theorem, approaching theory.

My definition of time is based on UTC time, the return from time(), and in reality, time is continuous, it always increases in a positive direction. There are man-made zones which are offsets from UTC, these are also continuous. Daylight Savings Time is a man-made local phenomenon, which is more or less a display on the wall but still tied to the continuous UTC-zone time.
This kinda looks like this:
UTC = 36000sec = 10 hours,
UTC(zone) has offset of 10 hours => 72000 = 20hours,
both continuously march forward, second for second,
UTC(zone) decides to enter DST game @ 73000 =>
UTC = 37000, UTC(zone) = 73000, UTC(zone+DST) = 73000 but wall displays 74000
mathematically: UTC(zone) = UTC(zone+DST) - DST = (STD display + DST) - DST, so UTC(zone+DST) - DST = DSTdisplay - DST,
UTC(zone+DST) = DSTdisplay
UTC(zone) decides we had enough @ 108000 UTC(zone)
UTC = 72000, UTC(zone) = 108000, UTC(zone+DST) wall displayed 109000, and now will display 108000.
This also allows the "fall back" times to have two display values yet separate UTC(zone) values =>
UTC(zone) = 107000 = DST wall display 108000 and
UTC(zone) = 108000 = STD wall display 108000.
For "spring forward" times there is no dead zone, see when they decided to enter game.
As for the guessing game, let's say mktime() created 108000 and a -1 was passed for isdst =>
Firstly, a value of 0 ties timezone to the STD offset, secondly, a value of 1 ties timezone to value of DST,
and by my definition a value of -1 means we enter with no knowledge of the timezone. A -1 forces us to use the UTC(zone) as a start point. From mktime value we find only one solution, 108000 is STD time.
For argument sake, let's use 107000 as input(mktime pre-timezone) with -1 again. UTC(zone) is start and we find 107000 is DST. We return DST and adjust for guess by updating the wall display.
For POSIX freaks, "broken-down time, expressed as local time" is defined as UTC(zone) with "A positive or 0 value for tm_isdst"(wall display) "presume"d "that Daylight Savings Time, respectively, is or is not in effect for the specified time" and "A negative value for tm_isdst" being "determine whether Daylight Savings Time is in effect for the specified time". For an incorrect presumption of postive, 0, or negative value, we correct "for timezone and any seasonal time adjustments" along with ranges and tm_wday and tm_yday components.

The only down side to this definition is when a town, state, country up and moves from their current location. This is not a newlib issue though, but included to provide full disclosure for you big cheeses of newlib to reach an opinion or decision. This moving of a UTC(zone) is a global positional move and not a local phenomenon. This is a condition of making that location a non-continuous time keeper. The condition can be addressed but needs extra fields and beyond the scope of this informational piece.

So, with this test (provided), and your aspirin (not included), review and please provide guidance on whether you wish a patch, which means my style writing and add ins, you wish to ignore, the test is bogus, or going to attempt yourselves.

Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: expose.c
Type: application/octet-stream
Size: 9634 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20111012/3b19a07b/attachment.obj>
-------------- next part --------------

PS. might want to comment out standard_format() test inclusion, or some of its zones, the difference list can be daunting, try just the 1970 years listings. God, I hope I got this right! Tough to explain.

```