Plain Black, makers of WebGUI - Date Problem -- Revisited

DBell

Date: 11/13/2006 5:25 pm · Subject: Date Problem -- Revisited · Rating: 0

I've been forced to take a good, long, hard look at the way date/times are handled in WebGUI.

It seems there was some discussion a few months back about this before the final 7.0 release (http://www.plainblack.com/date-problem), and it was decided that it was mishandled, but not enough to cause a major problem.

I've been reading a lot of documents on how to handle date/times, and I believe this could be more of a problem than first appears.

First, the documentation for Perl's DateTime module says that epoch times can't represent certain dates on some platforms. Of course, they don't give examples, so it's impossible to tell if this actually affects WebGUI. It also warns about different OSes starting the epoch at different times (which should be irrelevant to the Perl interpreter, for interoptability's sake).

Second, date/time calculations are done in the User's time zone, which has caused problems with those time zones that respect daylight savings time. DateTime.pm says that all calculations should ideally be done by first converting to UTC, doing the calculation, then converting back to the user's time zone.

Third, there looks to still be some methods in WebGUI::Session::DateTime that use simple arithmetic (with seconds) to calculate times. This simple arithmetic ignores leap seconds and DST changes (to make discrepancies of anywhere from 1 second to 1 hour).

Fourth, as a personal opinion, I think it'd be nicer to use hashes or hashrefs as parameters to the WebGUI::Session::DateTime methods.

With these in mind, I'd ask for opinions on changing the WebGUI::Session::DateTime API to more closely match DateTime.pm, even to go so far as making WebGUI::Session::DateTime just a child of DateTime, with additional WebGUI-specific methods for applying a user's timezone/locale settings.

This would have an added benefit of making localization of day and month names unnecessary (since the DateTime package provides methods and translations already).

Since it's an API change, it would have to be delegated to a major version change (either 8.x or 9.x).

Until then, it'd be possible to fix the mishandled time zones by simply applying the time zone after the arithmetic is done. By default, the DateTime->from_epoch() constructor sets a time zone of UTC.

Back to Top

Rate [ | ]

JT

Date: 11/13/2006 6:45 pm · Subject: Re: Date Problem -- Revisited · Rating: 1

I feel like I'm missing something. Are you talking outloud, asking
for opinions, suggesting a course of action, or something else? This
seems like it was just a conversation with yourself, but if it's not
please let me know what you're asking.

On Nov 13, 2006, at 5:25 PM, <doug@plainblack.com> wrote:

> DBell wrote:
>
> I've been forced to take a good, long, hard look at the way date/
> times are handled in WebGUI.
>
> It seems there was some discussion a few months back about this
> before the final 7.0 release (http://www.plainblack.com/date-
> problem), and it was decided that it was mishandled, but not enough
> to cause a major problem.
>
> I've been reading a lot of documents on how to handle date/times,
> and I believe this could be more of a problem than first appears.
>
> First, the documentation for Perl's DateTime module says that epoch
> times can't represent certain dates on some platforms. Of course,
> they don't give examples, so it's impossible to tell if this
> actually affects WebGUI. It also warns about different OSes
> starting the epoch at different times (which should be irrelevant
> to the Perl interpreter, for interoptability's sake).
>
> Second, date/time calculations are done in the User's time zone,
> which has caused problems with those time zo! nes that respect
> daylight savings time. DateTime.pm says that all calculations
> should ideally be done by first converting to UTC, doing the
> calculation, then converting back to the user's time zone.
>
> Third, there looks to still be some methods in
> WebGUI::Session::DateTime that use simple arithmetic (with seconds)
> to calculate times. This simple arithmetic ignores leap seconds and
> DST changes (to make discrepancies of anywhere from 1 second to 1
> hour).
>
> Fourth, as a personal opinion, I think it'd be nicer to use hashes
> or hashrefs as parameters to the WebGUI::Session::DateTime methods.
>
> With these in mind, I'd ask for opinions on changing the
> WebGUI::Session::DateTime API to more closely match DateTime.pm,
> even to go so far as making WebGUI::Session::DateTime just a child
> of DateTime, with additional WebGUI-specific methods for applying a
> user's timezone/locale settings.
>
> This would have an added benefit of making localization of day! and
> month names unnecessary (since the DateTime package provides meth
> ods and translations already).
>
> Since it's an API change, it would have to be delegated to a major
> version change (either 8.x or 9.x).
>
> Until then, it'd be possible to fix the mishandled time zones by
> simply applying the time zone after the arithmetic is done. By
> default, the DateTime->from_epoch() constructor sets a time zone of
> UTC.
>
>
>
> http://www.plainblack.com/webgui/dev/discuss/date-problem----revisited
> Unsubscribe
>
>
>
> --
>
> Plain Black, makers of WebGUI
> http://plainblack.com

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

I feel like I'm missing something. Are you talking outloud, asking for opinions, suggesting a course of action, or something else? This seems like it was just a conversation with yourself, but if it's not please let me know what you're asking.

On Nov 13, 2006, at 5:25 PM, <doug@plainblack.com> wrote:

DBell wrote:

I've been forced to take a good, long, hard look at the way date/times are handled in WebGUI.
It seems there was some discussion a few months back about this before the final 7.0 release (http://www.plainblack.com/date-problem), and it was decided that it was mishandled, but not enough to cause a major problem.
I've been reading a lot of documents on how to handle date/times, and I believe this could be more of a problem than first appears.
First, the documentation for Perl's DateTime module says that epoch times can't represent certain dates on some platforms. Of course, they don't give examples, so it's impossible to tell if this actually affects WebGUI. It also warns about different OSes starting the epoch at different times (which should be irrelevant to the Perl interpreter, for interoptability's sake).
Second, date/time calculations are done in the User's time zone, which has caused problems with those time zo! nes that respect daylight savings time. DateTime.pm says that all calculations should ideally be done by first converting to UTC, doing the calculation, then converting back to the user's time zone.
Third, there looks to still be some methods in WebGUI::Session::DateTime that use simple arithmetic (with seconds) to calculate times. This simple arithmetic ignores leap seconds and DST changes (to make discrepancies of anywhere from 1 second to 1 hour).
Fourth, as a personal opinion, I think it'd be nicer to use hashes or hashrefs as parameters to the WebGUI::Session::DateTime methods.
With these in mind, I'd ask for opinions on changing the WebGUI::Session::DateTime API to more closely match DateTime.pm, even to go so far as making WebGUI::Session::DateTime just a child of DateTime, with additional WebGUI-specific methods for applying a user's timezone/locale settings.
This would have an added benefit of making localization of day! and month names unnecessary (since the DateTime package provides meth ods and translations already).
Since it's an API change, it would have to be delegated to a major version change (either 8.x or 9.x).
Until then, it'd be possible to fix the mishandled time zones by simply applying the time zone after the arithmetic is done. By default, the DateTime->from_epoch() constructor sets a time zone of UTC.

http://www.plainblack.com/webgui/dev/discuss/date-problem----revisited
Unsubscribe

--
Plain Black, makers of WebGUIhttp://plainblack.com

JT ~ Plain Blackph: 703-286-2525 ext. 810fax: 312-264-5382http://www.plainblack.com
I reject your reality, and substitute my own. ~ Adam Savage

Back to Top

Rate [ | ]

DBell

Date: 11/14/2006 12:48 am · Subject: Re: Date Problem -- Revisited · Rating: -4

I'm asking for opinions on how to best implement a new date/time API.

Would WebGUI be best off by simply subclassing DateTime and adding any necessary methods?

Would it simply be best to try to fix what's already there?

Is there an entirely different way to go about it?

My opinion would be the first option.

Back to Top

Rate [ | ]

JT

Date: 11/14/2006 9:05 am · Subject: Re: Date Problem -- Revisited · Rating: 7

> I9m asking for opinions on how to best implement a new date/time API.

Ok.

> Would WebGUI be best off by simply subclassing DateTime and adding any necessary
>methods?
> Would it simply be best to try to fix what9s already there?
> Is there an entirely different way to go about it?
> My opinion would be the first option.

First I have to state, as you already have, that we cannot change the existing API.
However, we can certainly create an entirely new one. We can either create
$session->date (WebGUI::Session::Date) or WebGUI::DateTime if that makes more sense.
Then the other one will just be depricated, but continue to function as it does for the
next 3 years.

Yes, now that we're standardizing on DateTime I think that it would probably be ok to
subclass DateTime.

Since we'll be using the MySQL DateTime field to store the date in, we need to have a
constructor method that automatically parses that format (YYYY-MM-DD HH:MM:SS) so that
we don't have to manually parse it ala the normal hash mechanism that DateTime uses. We
should still have that constructor available as well, but we need both.

If no date is passed in to any constructor, it should always assume "now".

If it is $session->date then the constructor api's would look like:

my $hoursMinutesSeconds = $session->date->hms;
my $hoursMinutesSeconds = $session->date(datetime=>"2006-02-01 11:42:00")->hms;
my $hoursMinutesSeconds = $session->date(hash=>{year=>2006, month=>2, day=>1})->hms;
my $hoursMinutesSeconds = $session->date(epoch=>1003939393)->hms;

If it's a stand alone object the api's would look like:

use WebGUI::DateTime;
my $hoursMinutesSeconds = WebGUI::DateTime->new($session)->hms;
my $hoursMinutesSeconds = WebGUI::DateTime->new($session,"2006-02-01 11:42:00")->hms;
my $hoursMinutesSeconds = WebGUI::DateTime->newByHash($session, year=>2006, month=>2,
day=>1)->hms;
my $hoursMinutesSeconds = WebGUI::DateTime->newByEpoch(1003939393)->hms;

Under normal circumstances I'd say this should be it's own stand alone module. But since
dates are so prevelant everywhere in the system, I think the shorter session invocation
from a convenience point of view makes sense.

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 [ | ]

colink

Date: 11/19/2006 10:01 pm · Subject: Re: Date Problem -- Revisited · Rating: 1

No matter how you implement it, I'd strongly recommend writing a test suite for the new code. That way if we ever need to make changes to it in the future, we can know if the changes have unintentional side effects, like the time zone stuff we went through a little while ago.

Back to Top

Rate [ | ]

Date Problem -- Revisited

Recent Discussions Color Key