Re: RFC: msvcrt: support dates after year 2038 in mktime64

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=2394

Your paranoid android.


=== WINEBUILD (build) ===
Patch failed

RFC: msvcrt: support dates after year 2038 in mktime64

[James McKenzie]

(Marvin) wrote:
> Hi,
>
> While running your changed tests on Windows, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
> Full results can be found at
> http://testbot.winehq.org/JobDetails.pl?Key=2394
>
> Your paranoid android.
>
> === WINEBUILD (build) ===
> Patch failed

One question on this patch:

Does this duplicate activities within Vista/Windows7 (the only versions 
of Windows Retail that have 64 bitness)?

I had blocked out your ISP due to a large amount of unsolicited messages 
asking me to sign up with them.

James McKenzie

RFC: msvcrt: support dates after year 2038 in mktime64

[Robert Wilhelm]

Hello James,

seems I should better send patches as attachments.
http://testbot.winehq.org/JobDetails.pl?Key=2393 was more successfully.

I am not sure I got your question.
On 64bit unix systems (which have 64bit time_t), mktime() will support
dates after year 2038. There is no need for my patch.
 
Windows has mktime and _mktime64() already for ages. See
http://en.wikipedia.org/wiki/Year_2038_problem

Is it currently a problem to use gmx.net to send email to winehq?
I could use my googlemail acount instead.

Regards,
Robert


On Sun, 2010-05-30 at 10:23 -0700, James McKenzie wrote:
> (Marvin) wrote:
> > Hi,
> >
> > While running your changed tests on Windows, I think I found new failures.
> > Being a bot and all I'm not very good at pattern recognition, so I might be
> > wrong, but could you please double-check?
> > Full results can be found at
> > http://testbot.winehq.org/JobDetails.pl?Key=2394
> >
> > Your paranoid android.
> >
> > === WINEBUILD (build) ===
> > Patch failed
>
> One question on this patch:
>
> Does this duplicate activities within Vista/Windows7 (the only versions 
> of Windows Retail that have 64 bitness)?
>
> I had blocked out your ISP due to a large amount of unsolicited messages 
> asking me to sign up with them.
>
> James McKenzie

RFC: msvcrt: support dates after year 2038 in mktime64

[James McKenzie]

Robert Wilhelm wrote:
> Hello James,
>
> seems I should better send patches as attachments.
> http://testbot.winehq.org/JobDetails.pl?Key=2393 was more successfully.
>
> I am not sure I got your question.
> On 64bit unix systems (which have 64bit time_t), mktime() will support
> dates after year 2038. There is no need for my patch.
>
> Windows has mktime and _mktime64() already for ages. See
> http://en.wikipedia.org/wiki/Year_2038_problem

I think I know your confusion here.  Does UNIX and Windows implement 
these functions for the same date range or should we be rejecting a set 
of dates as being invalid?
> Is it currently a problem to use gmx.net to send email to winehq?
> I could use my googlemail acount instead.

No.  Please use your gmx.net account.  Wine developement and Wine 
patches will accept it.  I had blacklisted this ISP but I have removed 
them from the list as I have received no spam from them in a long time 
(there may have been a compromised computer or two that was sending 
stock 'pump and dump' messages to several Earthlink.net addresses.)

Also, please bottom post or interleave post.  Top posting makes message 
flow very hard to read.

James McKenzie

RFC: msvcrt: support dates after year 2038 in mktime64

[Robert Wilhelm]

On Sun, 2010-05-30 at 13:02 -0700, James McKenzie wrote:
> I think I know your confusion here.  Does UNIX and Windows implement 
> these functions for the same date range or should we be rejecting a set 
> of dates as being invalid?

Windows has 1970-2038 for mktime32 and 1970-3000 for _mktime64.


The lower border is ok:
Some Unix versions support dates before 1970. We already check for
negative numbers in wine and return -1 in this case. This is fine.

For upper border there is check for dates >3000 missing. Some Unix
systems support dates up to 9999.

There may be also corner cases at the borders (depending on timezone
etc.) which are different. But I doubt anybody will care.