Re: date manupulation strangeness
On Mon, Oct 29, 2007 at 01:19:51AM +, Miguel Lopes Santos Ramos wrote: From: Holger Kipp [EMAIL PROTECTED] On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: # unixtime=1193511599 # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime Sun Oct 28 02:59:59 KRAT 2007 Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really (cut-n-paste error, mea culpa). Take a note of zone name, KRAST stands for 'KRAsnoyarsk Summer Time' and KRAT stands for 'KRAsnoyarsk Time' (winter one). ah, I see. I can reproduce it here as well: %setenv LC_ALL C %setenv TZ Asia/Krasnoyarsk %setenv unixtime 1193511599 %date -jr $unixtime Sun Oct 28 02:59:59 KRAST 2007 %date -jf $s $unixtime Sun Oct 28 02:59:59 KRAT 2007 %date -juf %s $unixtime Sat Oct 27 18:59:59 UTC 2007 %date -jur $unixtime Sat Oct 27 18:59:59 UTC 2007 This is a lot of fun! Bugs like this go unnoticed for years... It is also very exciting finding people at GMT+8. Mind you, we programmers who live at GMT+0 do a lot of timezone errors because we look at a time and often don't know whether it's localtime or gmt. At least I do. Then we only find out when we change to summer time. The problem is of course in src/bin/date.c, line 268. Someone added the following on revision 1.32.2.4: 267:/* Let mktime() decide whether summer time is in effect. */ 268:lt-tm_isdst = -1; Now, who's mktime() to know? This line is erasing the output of strptime(), and strptime() knows better than anyone what the user might have wanted! [...] There's no point in naming the revision... the problematic line was introduced 6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision 1.32.2.4 Is ru around? Who fills in a pr for this? In summary, I think we should move line 268 to line 191 and erase the comment on line 267 (mktime() is no one to decide, strptime() must have the final word). I've committed a different fix, so that it doesn't re-introduce the bug fixed in rev. 1.36 (or 1.32.2.4, which was an MFC of 1.36). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
Ruslan Ermilov wrote: In summary, I think we should move line 268 to line 191 and erase the comment on line 267 (mktime() is no one to decide, strptime() must have the final word). I've committed a different fix, so that it doesn't re-introduce the bug fixed in rev. 1.36 (or 1.32.2.4, which was an MFC of 1.36). Thanks! Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
From: Mike Pritchard [EMAIL PROTECTED] [...] DST/CST time changes when setting the time backwards has been at your own risk for a long time. Yes, but there's really not much reason for it to be so much of a black art. Actually, I think the old behaviour, prior to rev 1.36, although not ideal was quite reasonable: it interpreted the user supplied date in the current time zone, say winter time, even though it refered to a period of summer time. It was that change that introduced a behaviour which IMHO must be regarded as a bug. Back in 1995/6 when I fixed a lot of utilities to enforce the password expiration date/time, I found it was off by +/- 1 hour if I was setting dates and times that would cross DST changes. Not a big deal then, but I think I got them all to work correctly. Well, the line of code I objected to is not that old. CVS blames someone called ru on revision 1.36 who committed changes submitted by Crist Clark in 2001. But if I recall correctly, if you wanted to really test those type of changes by setting the system date/time back, it was better to set the date/time to a period well before the DST change, verify the system understood it was in the proper time zone (probably a reboot), THEN move the clock up to just before the DST time change and let it roll over. There's not much point in doing that in this case, is there? All that is at stake here is if date translates from user supplied dates into a time_t in a predictable/justifiable manner. If it does/doesn't, rebooting and letting time pass won't do much good. The reason why I think that that must be seen as a bug is that date gave surprising results in a case where the user provided unmistakable input. Allow me to recall Eugene Grosbein / Holger Kipp's test case: %setenv LC_ALL C %setenv TZ Asia/Krasnoyarsk %setenv unixtime 1193511599 %date -jr $unixtime Sun Oct 28 02:59:59 KRAST 2007 %date -jf %s $unixtime Sun Oct 28 02:59:59 KRAT 2007 As you can see, the input to date is unmistakable, it is a time_t. The difference is that the second case forces date to use strptime() and the first doesn't. date is not outputing only the timezone wrong, those two dates are one hour appart. That means that in the first date is understanding 1193511599, and that in the second, at one point in its execution, date is understanding 1193615199, one hour latter. Trust me or add a printf to line 273. The line which is the cause for this misinterpretation is line 268. Before that line was introduced, behaviour was justifiable, although not ideal. If the user supplied unmistakable input, either a time_t or a date with explicit timezone, it worked, and when the user supplied date without timezone it always understood the date in the current timezone. This only had the inconvenient of +1/-1 when done across DST, but at least it wouldn't throw away the information supplied by the user. This line also makes date misinterpret full dates with timezone, not only time_ts for that limbo hour. In my opinion, we can have a bugless date for the limbo hour, and still solve the +1/-1 inconvenient simply by not destroying strptime()'s output. All it takes is to move 268 to line 191, as I said before. Of course, I don't think this is a critical or prioritary issue, not at all. It was only fun, because I could look into it in a half hour. But the kludge to solve the +1/-1 inconvenient is there and is ugly. Greetings Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
From: Holger Kipp [EMAIL PROTECTED]
On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote:
On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote:
# unixtime=1193511599
# LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime
Sun Oct 28 02:59:59 KRAT 2007
Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really
(cut-n-paste error, mea culpa). Take a note of zone name,
KRAST stands for 'KRAsnoyarsk Summer Time' and
KRAT stands for 'KRAsnoyarsk Time' (winter one).
ah, I see. I can reproduce it here as well:
%setenv LC_ALL C
%setenv TZ Asia/Krasnoyarsk
%setenv unixtime 1193511599
%date -jr $unixtime
Sun Oct 28 02:59:59 KRAST 2007
%date -jf $s $unixtime
Sun Oct 28 02:59:59 KRAT 2007
%date -juf %s $unixtime
Sat Oct 27 18:59:59 UTC 2007
%date -jur $unixtime
Sat Oct 27 18:59:59 UTC 2007
This is a lot of fun! Bugs like this go unnoticed for years...
It is also very exciting finding people at GMT+8. Mind you, we programmers who
live at
GMT+0 do a lot of timezone errors because we look at a time and often don't know
whether it's localtime or gmt. At least I do. Then we only find out when we
change to summer time.
The problem is of course in src/bin/date.c, line 268. Someone added the
following on revision 1.32.2.4:
267:/* Let mktime() decide whether summer time is in effect. */
268:lt-tm_isdst = -1;
Now, who's mktime() to know?
This line is erasing the output of strptime(), and strptime() knows better than
anyone what the user might have wanted!
See my test source code bellow. date first fills up a tm structure using
localtime(time(0)) so that the data which the user does not supply is extracted
from the current time. Then, it calls strptime to parse the user time using
these defaults. It's summarized in function test1() of my test code.
Historically, the behaviour was just this (actually, like test2()). The person
who added line 268, wanted to solve the problem of setting a date across DST,
but the way he/she did it is not, in my opinion, the best.
As we have discouvered, it does not work when the user supplies good DST data,
because the line tm_isdst = -1 erases it.
Now, what should perhaps be erased is the default dst data. So the line tm_isdst
= -1 should be moved up to line 191, between localtime() and strptime().
The code would behave like my test3() function.
See the test output (using LC_ALL=C and TZ=Asia/Krasnoyarsk):
Test1 using %s:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test1 using %Y-%m-%d %H:%M:%S:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test2 using %s:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test2 using %Y-%m-%d %H:%M:%S:
case a Sun Oct 28 02:59:59 KRAST 2007 != Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test3 using %s:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test3 using %Y-%m-%d %H:%M:%S:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Historical behaviour is test2. It didn't work across DST when the user didn't
supply DST data, but it did work fine for %s.
The correction, test1, introduced the error you've spotted, and that would
only have been spotted by someone concerned with those two hours of each year...
The solution I think its best works always that the user supplies DST data. Of
course, it fails to guess dst status for test case b, but that's understandable,
it can't guess.
Looks like one of the conversions is getting the
summertime-flag wrong here.
I have tested this here with 6.2-STABLE from May 20...
There's no point in naming the revision... the problematic line was introduced
6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision
1.32.2.4
Is ru around?
Who fills in a pr for this?
In summary, I think we should move line 268 to line 191 and erase the comment
on line 267 (mktime() is no one to decide, strptime() must have the final word).
Miguel Ramos
Lisboa, Portugal
#include stdio.h
#include string.h
#include time.h
time_t test1(const char* datestr, const char* format)
{
time_t t = time(0);
Re: date manupulation strangeness
On Mon, Oct 29, 2007 at 01:19:51AM +, Miguel Lopes Santos Ramos wrote: From: Holger Kipp [EMAIL PROTECTED] On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: Sat Oct 27 18:59:59 UTC 2007 This is a lot of fun! Bugs like this go unnoticed for years... It is also very exciting finding people at GMT+8. Mind you, we programmers who live at GMT+0 do a lot of timezone errors because we look at a time and often don't know whether it's localtime or gmt. At least I do. Then we only find out when we change to summer time. The problem is of course in src/bin/date.c, line 268. Someone added the following on revision 1.32.2.4: 267:/* Let mktime() decide whether summer time is in effect. */ 268:lt-tm_isdst = -1; Now, who's mktime() to know? This line is erasing the output of strptime(), and strptime() knows better than anyone what the user might have wanted! See my test source code bellow. date first fills up a tm structure using localtime(time(0)) so that the data which the user does not supply is extracted from the current time. Then, it calls strptime to parse the user time using these defaults. It's summarized in function test1() of my test code. Historically, the behaviour was just this (actually, like test2()). The person who added line 268, wanted to solve the problem of setting a date across DST, but the way he/she did it is not, in my opinion, the best. As we have discouvered, it does not work when the user supplies good DST data, because the line tm_isdst = -1 erases it. Now, what should perhaps be erased is the default dst data. So the line tm_isdst = -1 should be moved up to line 191, between localtime() and strptime(). The code would behave like my test3() function. See the test output (using LC_ALL=C and TZ=Asia/Krasnoyarsk): [lots of stuff trimmed from the above] DST/CST time changes when setting the time backwards has been at your own risk for a long time. Back in 1995/6 when I fixed a lot of utilities to enforce the password expiration date/time, I found it was off by +/- 1 hour if I was setting dates and times that would cross DST changes. Not a big deal then, but I think I got them all to work correctly. But if I recall correctly, if you wanted to really test those type of changes by setting the system date/time back, it was better to set the date/time to a period well before the DST change, verify the system understood it was in the proper time zone (probably a reboot), THEN move the clock up to just before the DST time change and let it roll over. -- Mike Pritchard mpp @ FreeBSD.org If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy. - James Madison (1787) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
date manupulation strangeness
Hi! # unixtime=1193511599 # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime Sun Oct 28 02:59:59 KRAT 2007 That's last second of Summer time in this time zone. # LC_ALL=C TZ=Asia/Krasnoyarsk date -f %s $unixtime Sun Oct 28 02:59:59 KRAT 2007 That's an hour later after the switch from Summer time, but how can it be? It is a bug? Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
On Mon, Oct 29, 2007 at 12:48:32AM +0700, Eugene Grosbein wrote: Hi! # unixtime=1193511599 # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime Sun Oct 28 02:59:59 KRAT 2007 That's last second of Summer time in this time zone. # LC_ALL=C TZ=Asia/Krasnoyarsk date -f %s $unixtime Sun Oct 28 02:59:59 KRAT 2007 That's an hour later after the switch from Summer time, but how can it be? It is a bug? I haven't checked, but usually during switch from summer to winter time, you change the clock back from 03:00 to 02:00, so you have the same hour twice. So you have 02:59:59 summer time and then you have (instead of 03:00:00) 02:00:00 winter time a second later, so one hour later you end up with 02:59:59 again. Best regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: # unixtime=1193511599 # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime Sun Oct 28 02:59:59 KRAT 2007 Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really (cut-n-paste error, mea culpa). Take a note of zone name, KRAST stands for 'KRAsnoyarsk Summer Time' and KRAT stands for 'KRAsnoyarsk Time' (winter one). That's last second of Summer time in this time zone. # LC_ALL=C TZ=Asia/Krasnoyarsk date -f %s $unixtime Sun Oct 28 02:59:59 KRAT 2007 That's an hour later after the switch from Summer time, but how can it be? It is a bug? I haven't checked, but usually during switch from summer to winter time, you change the clock back from 03:00 to 02:00, so you have the same hour twice. So you have 02:59:59 summer time and then you have (instead of 03:00:00) 02:00:00 winter time a second later, so one hour later you end up with 02:59:59 again. Yes, but 02:59:59 KRAT is one hour (minus one second) later than 02:00:00 KRAT, the latter equals to 03:00:00 KRAST, so the first invocation of 'date' command shows time an hour before time the second invocation shows. However, unixtime is the same. That bothers me, something is wrong. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: # unixtime=1193511599 # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime Sun Oct 28 02:59:59 KRAT 2007 Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really (cut-n-paste error, mea culpa). Take a note of zone name, KRAST stands for 'KRAsnoyarsk Summer Time' and KRAT stands for 'KRAsnoyarsk Time' (winter one). ah, I see. I can reproduce it here as well: %setenv LC_ALL C %setenv TZ Asia/Krasnoyarsk %setenv unixtime 1193511599 %date -jr $unixtime Sun Oct 28 02:59:59 KRAST 2007 %date -jf $s $unixtime Sun Oct 28 02:59:59 KRAT 2007 %date -juf %s $unixtime Sat Oct 27 18:59:59 UTC 2007 %date -jur $unixtime Sat Oct 27 18:59:59 UTC 2007 Interestingly, if output is forced to be in UTC, both give the same results. Using unixtime 1193511600 instead, I get %date -jr $unixtime Sun Oct 28 02:00:00 KRAT 2007 %date -jf %s $unixtime Sun Oct 28 02:00:00 KRAST 2007 With unixtime 1193509360 both return KRAST and with unixtime 1193512959 both return KRAT. In between, one returns KRAST, the other KRAT or vice versa... Looks like one of the conversions is getting the summertime-flag wrong here. I have tested this here with 6.2-STABLE from May 20... Regards, Holger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
From: Holger Kipp [EMAIL PROTECTED]
On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote:
On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote:
# unixtime=1193511599
# LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime
Sun Oct 28 02:59:59 KRAT 2007
Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really
(cut-n-paste error, mea culpa). Take a note of zone name,
KRAST stands for 'KRAsnoyarsk Summer Time' and
KRAT stands for 'KRAsnoyarsk Time' (winter one).
ah, I see. I can reproduce it here as well:
%setenv LC_ALL C
%setenv TZ Asia/Krasnoyarsk
%setenv unixtime 1193511599
%date -jr $unixtime
Sun Oct 28 02:59:59 KRAST 2007
%date -jf $s $unixtime
Sun Oct 28 02:59:59 KRAT 2007
%date -juf %s $unixtime
Sat Oct 27 18:59:59 UTC 2007
%date -jur $unixtime
Sat Oct 27 18:59:59 UTC 2007
This is a lot of fun! Bugs like this go unnoticed for years...
It is also very exciting finding people at GMT+8. Mind you, we programmers who
live at
GMT+0 do a lot of timezone errors because we look at a time and often don't know
whether it's localtime or gmt. At least I do. Then we only find out when we
change to summer time.
The problem is of course in src/bin/date.c, line 268. Someone added the
following on revision 1.32.2.4:
267:/* Let mktime() decide whether summer time is in effect. */
268:lt-tm_isdst = -1;
Now, who's mktime() to know?
This line is erasing the output of strptime(), and strptime() knows better than
anyone what the user might have wanted!
See my test source code bellow. date first fills up a tm structure using
localtime(time(0)) so that the data which the user does not supply is extracted
from the current time. Then, it calls strptime to parse the user time using
these defaults. It's summarized in function test1() of my test code.
Historically, the behaviour was just this (actually, like test2()). The person
who added line 268, wanted to solve the problem of setting a date across DST,
but the way he/she did it is not, in my opinion, the best.
As we have discouvered, it does not work when the user supplies good DST data,
because the line tm_isdst = -1 erases it.
Now, what should perhaps be erased is the default dst data. So the line tm_isdst
= -1 should be moved up to line 191, between localtime() and strptime().
The code would behave like my test3() function.
See the test output (using LC_ALL=C and TZ=Asia/Krasnoyarsk):
Test1 using %s:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test1 using %Y-%m-%d %H:%M:%S:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test2 using %s:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test2 using %Y-%m-%d %H:%M:%S:
case a Sun Oct 28 02:59:59 KRAST 2007 != Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test3 using %s:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Test3 using %Y-%m-%d %H:%M:%S:
case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007
case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007
case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007
Historical behaviour is test2. It didn't work across DST when the user didn't
supply DST data, but it did work fine for %s.
The correction, test1, introduced the error you've spotted, and that would
only have been spotted by someone concerned with those two hours of each year...
The solution I think its best works always that the user supplies DST data. Of
course, it fails to guess dst status for test case b, but that's understandable,
it can't guess.
Looks like one of the conversions is getting the
summertime-flag wrong here.
I have tested this here with 6.2-STABLE from May 20...
There's no point in naming the revision... the problematic line was introduced
6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision
1.32.2.4
Is ru around?
Who fills in a pr for this?
In summary, I think we should move line 268 to line 191 and erase the comment
on line 267 (mktime() is no one to decide, strptime() must have the final word).
Miguel Ramos
Lisboa, Portugal
#include stdio.h
#include string.h
#include time.h
time_t test1(const char* datestr, const char* format)
{
time_t t = time(0);
