Plain Black, makers of WebGUI

JT

Date: 6/12/2006 5:50 pm · Subject: date problem · Rating: 25

We have ourselves a date problem, and I'm not sure what to do about it. The problem is
that epochs use int() internally in perl, and therefore they are simply 32 bit signed
integers, and therefore epoch cannot go larger than the year 2038.

By the time we get to 2038 we'll be using 64 bit processors, I'm sure so it won't be a
problem then. However, right now if someone wants to assign something to happen on 2046
they can't do it because perl chokes on it.

The DateTime guys solve this by breaking dates into their component parts internally,
and thusly are using relatively small integers. However, WebGUI uses epochs everywhere.
In the database we store this as bigint, so we don't have a problem. But in code, we
have only two ways of solving it.

A) Stick with it the way it is realizing that people will only be able to set dates
beyond 2038 if they have 64 bit hardware and a 64 bit compiled perl.

B) Rewrite all date related functions in WebGUI to use a physical date format like
2006-06-12 13:44:01. And then we'd be used DateTime natively rather than using epochs
for stuff.

The advantage of A is that we're already done. The disadvantage is that there will be
some people who may want to set dates a fair amount in the future.

The advantage of B is that we can then handle dates up to 10,000 years into the future.
The disadvantage is that we're pretty late into the 7.0 beta cycle to be rewriting a
major component like this. However, if we're going to do it, this is the time to do it,
because when 7.0 goes gold, there's no breaking the API for a good long while.

What does everyone think?

JT ~ Plain Black
ph: 703-286-2525 ext. 810
fax: 312-264-5382
http://www.plainblack.com

I reject your reality, and substitute my own. ~ Adam Savage

Back to Top

Rate [ | ]

snapcount

Date: 6/12/2006 6:05 pm · Subject: Re: date problem · Rating: 8

I vote for A. This is why:

1) Big change that affects a lot of code and provide relatively
little benefit. Risk/work outweighs usefulness.

2) I think it's completely unrealistic to think that someone will
still be running 32 bit hardware by the time the date actually got
here to do whatever they wanted. I'm not trying to repeat what you
said, what I'm saying is that the only real reason to change this
would be if someone genuinely had a need to make something actually
happen on a date that far in the future. 32 years ago computers took
up entire rooms and/or buildings so I'd say it's safe to assume
hardware will change by the time the date gets here. The reason
people set things that far ahead is to imply "forever" and 2038 is
just as good as 10,000 years from now for that in my opinion.

Roy

On Jun 12, 2006, at 6:50 PM, webguidev@plainblack.com wrote:

>
> JT has posted to one of your subscriptions
> http://www.plainblack.com/date-problem
> We have ourselves a date problem, and I'm not sure what to do about
> it. The problem is
> that epochs use int() internally in perl, and therefore they are
> simply 32 bit signed
> integers, and therefore epoch cannot go larger than the year 2038.
>
> By the time we get to 2038 we'll be using 64 bit processors, I'm
> sure so it won't be a
> problem then. However, right now if someone wants to assign
> something to happen on 2046
> they can't do it because perl chokes on it.
>
> The DateTime guys solve this by breaking dates into their component
> parts internally,
> and thusly are using relatively small integers. However, WebGUI
> uses epochs everywhere.
> In the database we store this as bigint, so we don't have a
> problem. But in code, we
> have only two ways of solving it.
>
> A) Stick with it the way it is realizing that people will only be
> able to set dates
> beyond 2038 if they have 64 bit hardware and a 64 bit compiled perl.
>
> B) Rewrite all date related functions in WebGUI to use a physical
> date format like
> 2006-06-12 13:44:01. And then we'd be used DateTime natively rather
> than using epochs
> for stuff.
>
> The advantage of A is that we're already done. The disadvantage is
> that there will be
> some people who may want to set dates a fair amount in the future.
>
> The advantage of B is that we can then handle dates up to 10,000
> years into the future.
> The disadvantage is that we're pretty late into the 7.0 beta cycle
> to be rewriting a
> major component like this. However, if we're going to do it, this
> is the time to do it,
> because when 7.0 goes gold, there's no breaking the API for a good
> long while.
>
> What does everyone think?
>
> JT ~ Plain Black
> ph: 703-286-2525 ext. 810
> fax: 312-264-5382
> http://www.plainblack.com
>
> I reject your reality, and substitute my own. ~ Adam Savage
>
>
>
> Plain Black, makers of WebGUI
> info@plainblack.com
> http://plainblack.com

I vote for A. This is why:
1) Big change that affects a lot of code and provide relatively little benefit. Risk/work outweighs usefulness.
2) I think it's completely unrealistic to think that someone will still be running 32 bit hardware by the time the date actually got here to do whatever they wanted. I'm not trying to repeat what you said, what I'm saying is that the only real reason to change this would be if someone genuinely had a need to make something actually happen on a date that far in the future. 32 years ago computers took up entire rooms and/or buildings so I'd say it's safe to assume hardware will change by the time the date gets here. The reason people set things that far ahead is to imply "forever" and 2038 is just as good as 10,000 years from now for that in my opinion.
Roy
On Jun 12, 2006, at 6:50 PM, webguidev@plainblack.com wrote:

JT has posted to one of your subscriptionshttp://www.plainblack.com/date-problemWe have ourselves a date problem, and I'm not sure what to do about it. The problem is
that epochs use int() internally in perl, and therefore they are simply 32 bit signed
integers, and therefore epoch cannot go larger than the year 2038.

By the time we get to 2038 we'll be using 64 bit processors, I'm sure so it won't be a
problem then. However, right now if someone wants to assign something to happen on 2046
they can't do it because perl chokes on it.

The DateTime guys solve this by breaking dates into their component parts internally,
and thusly are using relatively small integers. However, WebGUI uses epochs everywhere.
In the database we store this as bigint, so we don't have a problem. But in code, we
have only two ways of solving it.

A) Stick with it the way it is realizing that people will only be able to set dates
beyond 2038 if they have 64 bit hardware and a 64 bit compiled perl.

B) Rewrite all date related functions in WebGUI to use a physical date format like
2006-06-12 13:44:01. And then we'd be used DateTime natively rather than using epochs
for stuff.

The advantage of A is that we're already done. The disadvantage is that there will be
some people who may want to set dates a fair amount in the future.

The advantage of B is that we can then handle dates up to 10,000 years into the future.
The disadvantage is that we're pretty late into the 7.0 beta cycle to be rewriting a
major component like this. However, if we're going to do it, this is the time to do it,
because when 7.0 goes gold, there's no breaking the API for a good long while.

What does everyone think?

JT ~ Plain Black
ph: 703-286-2525 ext. 810
fax: 312-264-5382
http://www.plainblack.com

I reject your reality, and substitute my own. ~ Adam Savage

Plain Black, makers of WebGUIinfo@plainblack.com http://plainblack.com

Back to Top

Rate [ | ]

len

Date: 6/12/2006 6:20 pm · Subject: Re: date problem · Rating: 10

Is there any good reason to keep the epoch format ?

Does option 2 implies the usage of MySQL datetime fields ? MySQL
is quite good (and fast) in handling date/time stuff.

We could choose a hybrid solution where we let MySQL do most of
the date handling and use DateTime for situations where MySQL's
datetime functions do not suffice ?

Len

----- Original Message -----
From: webguidev@plainblack.com
To: len@primaat.com
Sent: Tuesday, June 13, 2006 12:50 AM
Subject: [wg-dev] date problem

JT has posted to one of your subscriptions
http://www.plainblack.com/date-problem
We have ourselves a date problem, and I'm not sure what to do about
it. The problem is
that epochs use int() internally in perl, and therefore they are
simply 32 bit signed
integers, and therefore epoch cannot go larger than the year 2038.

By the time we get to 2038 we'll be using 64 bit processors, I'm
sure so it won't be a
problem then. However, right now if someone wants to assign
something to happen on 2046
they can't do it because perl chokes on it.

The DateTime guys solve this by breaking dates into their component
parts internally,
and thusly are using relatively small integers. However, WebGUI uses
epochs everywhere.
In the database we store this as bigint, so we don't have a problem.
But in code, we
have only two ways of solving it.

A) Stick with it the way it is realizing that people will only be
able to set dates
beyond 2038 if they have 64 bit hardware and a 64 bit compiled perl.

B) Rewrite all date related functions in WebGUI to use a physical
date format like
2006-06-12 13:44:01. And then we'd be used DateTime natively rather
than using epochs
for stuff.

The advantage of A is that we're already done. The disadvantage is
that there will be
some people who may want to set dates a fair amount in the future.

The advantage of B is that we can then handle dates up to 10,000
years into the future.
The disadvantage is that we're pretty late into the 7.0 beta cycle
to be rewriting a
major component like this. However, if we're going to do it, this is
the time to do it,
because when 7.0 goes gold, there's no breaking the API for a good
long while.

What does everyone think?

JT ~ Plain Black
ph: 703-286-2525 ext. 810
fax: 312-264-5382
http://www.plainblack.com

I reject your reality, and substitute my own. ~ Adam Savage

----------------------------------------------------------------------------
--

Plain Black, makers of WebGUI
info@plainblack.com
http://plainblack.com
ï»¿<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> Is there any good reason to keep the epoch format ? Does option 2 implies the usage of MySQL datetime fields ? MySQL is quite good (and fast) in handling date/time stuff. We could choose a hybrid solution where we let MySQL do most of the date handling and use DateTime for situations where MySQL's datetime functions do not suffice ? Len ----- Original Message -----

From: webguidev@plainblack.com To: len@primaat.com Sent: Tuesday, June 13, 2006 12:50 AM Subject: [wg-dev] date problem
JT has posted to one of your subscriptions http://www.plainblack.com/date-problem We have ourselves a date problem, and I'm not sure what to do about it. The problem is
that epochs use int() internally in perl, and therefore they are simply 32 bit signed
integers, and therefore epoch cannot go larger than the year 2038.

By the time we get to 2038 we'll be using 64 bit processors, I'm sure so it won't be a
problem then. However, right now if someone wants to assign something to happen on 2046
they can't do it because perl chokes on it.

The DateTime guys solve this by breaking dates into their component parts internally,
and thusly are using relatively small integers. However, WebGUI uses epochs everywhere.
In the database we store this as bigint, so we don't have a problem. But in code, we
have only two ways of solving it.

A) Stick with it the way it is realizing that people will only be able to set dates
beyond 2038 if they have 64 bit hardware and a 64 bit compiled perl.

B) Rewrite all date related functions in WebGUI to use a physical date format like
2006-06-12 13:44:01. And then we'd be used DateTime natively rather than using epochs
for stuff.

The advantage of A is that we're already done. The disadvantage is that there will be
some people who may want to set dates a fair amount in the future.

The advantage of B is that we can then handle dates up to 10,000 years into the future.
The disadvantage is that we're pretty late into the 7.0 beta cycle to be rewriting a
major component like this. However, if we're going to do it, this is the time to do it,
because when 7.0 goes gold, there's no breaking the API for a good long while.

What does everyone think?

JT ~ Plain Black
ph: 703-286-2525 ext. 810
fax: 312-264-5382
http://www.plainblack.com

I reject your reality, and substitute my own. ~ Adam Savage

Plain Black, makers of WebGUI
info@plainblack.com
http://plainblack.com

Back to Top

Rate [ | ]

JT

Date: 6/12/2006 6:27 pm · Subject: Re: date problem · Rating: 4

The only reasons to keep the epoch format are that it's easy to work with and that's what we've already got in place (therefore no work to keep it).

Yes, option two does imply the usage of MySQL date time fields. So yes it would be possible to use MySQL date time functions for some database related calculations, which would speed up certain things tremendously.

I should note that doing this would likely delay the release of WebGUI 7 (stable) by two weeks. I'd do anything I can to get it done as quickly as possible, but this is a BIG change.

Back to Top

Rate [ | ]

fdillon

Date: 6/12/2006 8:25 pm · Subject: RE: Re: date problem · Rating: 17

I think the way we deal with dates right now as epochs is ultimately
flawed, however I'm torn b/c I really don't think we can afford to hold
up the release of WebGUI 7 and I think 2 weeks is a pretty severe
underestimate as we will definitely have to go back to beta before we
have a stable release.

I guess I'm ultimately for pushing this off until the next API breaking
release of WebGUI down the road. Waiting 3-5 years to make this change
won't severely limit progress IMO.

Frank Dillon
Plain Black Corporation
Phone: +1 (703) 286-2525 x840
Fax: +1 (312) 264-5382
-----Original Message-----
From: webguidev@plainblack.com [mailto:webguidev@plainblack.com]
Sent: Monday, June 12, 2006 6:27 PM
To: frank@plainblack.com
Subject: [wg-dev] Re: date problem

JT has posted to one of your subscriptions

http://www.plainblack.com/date-problem/3

The only reasons to keep the epoch format are that it's easy to work
with and that's what we've already got in place (therefore no work to
keep it).
Yes, option two does imply the usage of MySQL date time fields. So yes
it would be possible to use MySQL date time functions for some database
related calculations, which would speed up certain things tremendously.
I should note that doing this would likely delay the release of WebGUI 7
(stable) by two weeks. I'd do anything I can to get it done as quickly
as possible, but this is a BIG change.

I think the way we deal with dates right now as epochs is ultimately flawed, however I’m torn b/c I really don’t think we can afford to hold up the release of WebGUI 7 and I think 2 weeks is a pretty severe underestimate as we will definitely have to go back to beta before we have a stable release.

I guess I’m ultimately for pushing this off until the next API breaking release of WebGUI down the road. Waiting 3-5 years to make this change won’t severely limit progress IMO.

Frank Dillon
Plain Black Corporation
Phone: +1 (703) 286-2525 x840
Fax: +1 (312) 264-5382

-----Original Message-----
From: webguidev@plainblack.com [mailto:webguidev@plainblack.com]
Sent: Monday, June 12, 2006 6:27 PM
To: frank@plainblack.com
Subject: [wg-dev] Re: date problem

JT has posted to one of your subscriptions

http://www.plainblack.com/date-problem/3

The only reasons to keep the epoch format are that it's easy to work with and that's what we've already got in place (therefore no work to keep it).

Yes, option two does imply the usage of MySQL date time fields. So yes it would be possible to use MySQL date time functions for some database related calculations, which would speed up certain things tremendously.

I should note that doing this would likely delay the release of WebGUI 7 (stable) by two weeks. I'd do anything I can to get it done as quickly as possible, but this is a BIG change.

Back to Top

Rate [ | ]

ekennedy

Date: 6/13/2006 5:43 am · Subject: Re: date problem · Rating: 15

I'm anxious to have 7.0 out too, however, if it would really only set things back a couple of weeks to eliminate the use of the epoch for dates I would vote to do it now rather than wait until the next major API change.

Back to Top

Rate [ | ]

ckotil

Date: 6/13/2006 7:30 am · Subject: Re: date problem · Rating: 11

I vote option A much for the same reasons as snapcount. 2038 is a LONG was away. I anticipate to be using WebGUI's 3rd or 4th successor by then. My orginization will not need to plan out dates that far into the future. Also within a few years time, im sure we will be running WebGUI on 64 bit architechture and therefore this problem will disappear into the vaults of 'code bugs that almost got the best of us'.

-ckotil

Back to Top

Rate [ | ]

crythias

Date: 6/13/2006 9:14 am · Subject: Re: date problem · Rating: 10

Is there a way to *ahem* simply accept the db's epoch, change it to DateTime YYYYMMDDHHMMSS or whatever (maybe even via mysql query) and hand it off quietly?

If people are going to use the calendar for things like mortgages, they'll need 30+ years, quickly.

Respectfully, I'd ask to fix it now (B). It's important to make 7 the best. Can I donate 1000 karma? :) :) :)

Back to Top

Rate [ | ]

JT

Date: 6/13/2006 10:33 am · Subject: Re: date problem · Rating: 25

It seems we're pretty divided on this issue as a group.

I will have to concede to Frank that my estimate of a two week push is probably agressive. However, I don't think it's grossly underestimated. I think it is quite possible to finish the changes and betas within the two week time frame. The problem that could arise is other stuff getting in the way. For example, I'm speaking at YAPC at the end of the month, and moving at the end of the month. There could be a rush of support requests. We could take on some new clients that need my assistance. So from that vantage point it may take more like 3-4 weeks.

I see the point of those saying that WebGUI 7 should be the best it can be. I agree with that. But I'm not sure that this flaw is really a detriment to WebGUI 7. I think worst case scenario it's it means nothing to most people and is an annoyance to a few.

I have to agree with the people that said that this is not a short term problem, but rather a long term one, and a problem that will in fact go away with 64 bit hardware. Though it may go away, I do think we should keep this on the list of changes for the next big WebGUI change several years down the line. The epoch problem will go away, but ultimately as Len said, certain areas of WebGUI could perform faster if we were calculating dates in the database rather than in WebGUI.

I think it's time to kill the scope creep and just get WebGUI 7 out. This is just barely a bug, and one we can live with.

Back to Top

Rate [ | ]

date problem

Recent Discussions Color Key