You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by mark goldin <ma...@gmail.com> on 2013/09/11 23:17:39 UTC

New Date issues

I am working on what appears to be a bug, but I am not sure where exactly.
I am creating a new date without specifying a time portion. So, hours and
seconds are equal 0.
If this date is between March 10 and March 23 (did not try all a way to the
end of March) then according to Charles a date that is sent to the server
is one day less. Any other month is not affected by this potential bug.
Anyone has any explanation?

Thanks

Re: New Date issues

Posted by Mattchoo <ma...@mattchoo.com>.
A good practice is to send dates (where time is not relevant) as strings 

Sent from my iPhone

On Sep 12, 2013, at 5:45 AM, Tom Chiverton <tc...@extravision.com> wrote:

> On 12/09/2013 09:22, Justin Mclean wrote:
>> Hi,
>> 
>>> Whenever we want a date to mean a particular day, we set the hours to 12, which almost always solves the problem with out too many changes.
>> Given a limited range of time zones that should work.
>> 
>> You may still have to be careful if your application is used world wide eg take New Zealand Australia (+12) and USA West Cost (-8) and there's a 20 hour time difference.
> Yeah, it's a safety net only really - but in our case everything is mediated by a server in UTC so the two extremes are never directly compared on the client, and both should agree on the days between dates.
> 
> Tom
> 

Re: New Date issues

Posted by mark goldin <ma...@gmail.com>.
<They changed the date by 3 weeks or so.  So all dates in that range are
affected.
What is that you are taking about?


On Thu, Sep 12, 2013 at 7:45 AM, Tom Chiverton <tc...@extravision.com> wrote:

> On 12/09/2013 09:22, Justin Mclean wrote:
>
>> Hi,
>>
>>  Whenever we want a date to mean a particular day, we set the hours to
>>> 12, which almost always solves the problem with out too many changes.
>>>
>> Given a limited range of time zones that should work.
>>
>> You may still have to be careful if your application is used world wide
>> eg take New Zealand Australia (+12) and USA West Cost (-8) and there's a 20
>> hour time difference.
>>
>>  Yeah, it's a safety net only really - but in our case everything is
> mediated by a server in UTC so the two extremes are never directly compared
> on the client, and both should agree on the days between dates.
>
> Tom
>

Re: New Date issues

Posted by Tom Chiverton <tc...@extravision.com>.
On 12/09/2013 09:22, Justin Mclean wrote:
> Hi,
>
>> Whenever we want a date to mean a particular day, we set the hours to 12, which almost always solves the problem with out too many changes.
> Given a limited range of time zones that should work.
>
> You may still have to be careful if your application is used world wide eg take New Zealand Australia (+12) and USA West Cost (-8) and there's a 20 hour time difference.
>
Yeah, it's a safety net only really - but in our case everything is 
mediated by a server in UTC so the two extremes are never directly 
compared on the client, and both should agree on the days between dates.

Tom

Re: New Date issues

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Whenever we want a date to mean a particular day, we set the hours to 12, which almost always solves the problem with out too many changes.

Given a limited range of time zones that should work.

You may still have to be careful if your application is used world wide eg take New Zealand Australia (+12) and USA West Cost (-8) and there's a 20 hour time difference.

Thanks,
Justin

Re: New Date issues

Posted by Tom Chiverton <tc...@extravision.com>.
Whenever we want a date to mean a particular day, we set the hours to 
12, which almost always solves the problem with out too many changes.

Tom

On 11/09/2013 22:47, Justin Mclean wrote:
> The best way around this issue (if you can) is to send time/date as UTC (milliseconds) or as a string representing the date eg (YYYY-MM-DD) to try and avoid the automatic timezone conversion done by the Flash Player.


Re: New Date issues

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> They changed the date by 3 weeks or so.  So all dates in that range are
> affected.  Might happen during the fall "back" time period too.

From memory I think FP has a single set of dates for daylight saving time (per locale) and not a database year by year so has issues with DST depending on how far back you go.

The official documentation generally helps:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Date.html

"However, the transition dates currently in effect are applied to dates in the past and the future, so the daylight saving time bias might calculate incorrectly for dates in the past when the locale had different transition dates."

Thanks,
Justin

RE: New Date issues

Posted by Matthew OMeara <ma...@mattchoo.com>.
They changed the date by 3 weeks or so.  So all dates in that range are
affected.  Might happen during the fall "back" time period too.

Basically, somewhere in the stack of date translation something has the
wrong logic, likely it is the OS... are they on an old unpatched OS?

-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com] 
Sent: Wednesday, September 11, 2013 2:47 PM
To: users@flex.apache.org
Subject: Re: New Date issues

Hi,

> I would think so to, but why are multiple days in March affected? Not 
> just one day when DST actually happens?

At a guess because all time from that date as converted to an hour less make
the dates one day before and the hours 23:00. The problem gets worse when
the user machine is set to a different timezone to the server.

The best way around this issue (if you can) is to send time/date as UTC
(milliseconds) or as a string representing the date eg (YYYY-MM-DD) to try
and avoid the automatic timezone conversion done by the Flash Player.

Thanks,
Justin


Re: New Date issues

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> I would think so to, but why are multiple days in March affected? Not just
> one day when DST actually happens?

At a guess because all time from that date as converted to an hour less make the dates one day before and the hours 23:00. The problem gets worse when the user machine is set to a different timezone to the server.

The best way around this issue (if you can) is to send time/date as UTC (milliseconds) or as a string representing the date eg (YYYY-MM-DD) to try and avoid the automatic timezone conversion done by the Flash Player.

Thanks,
Justin

Re: New Date issues

Posted by mark goldin <ma...@gmail.com>.
I would think so to, but why are multiple days in March affected? Not just
one day when DST actually happens?


On Wed, Sep 11, 2013 at 4:25 PM, Matthew OMeara <ma...@mattchoo.com> wrote:

> This sounds like an issue regarding the change by the US government to
> which
> days daylight savings time happens on
>
> This occurred about 6 years ago under Bush
>
> -----Original Message-----
> From: mark goldin [mailto:markzolotoy@gmail.com]
> Sent: Wednesday, September 11, 2013 2:18 PM
> To: users
> Subject: New Date issues
>
> I am working on what appears to be a bug, but I am not sure where exactly.
> I am creating a new date without specifying a time portion. So, hours and
> seconds are equal 0.
> If this date is between March 10 and March 23 (did not try all a way to the
> end of March) then according to Charles a date that is sent to the server
> is
> one day less. Any other month is not affected by this potential bug.
> Anyone has any explanation?
>
> Thanks
>
>

RE: New Date issues

Posted by Matthew OMeara <ma...@mattchoo.com>.
This sounds like an issue regarding the change by the US government to which
days daylight savings time happens on

This occurred about 6 years ago under Bush

-----Original Message-----
From: mark goldin [mailto:markzolotoy@gmail.com] 
Sent: Wednesday, September 11, 2013 2:18 PM
To: users
Subject: New Date issues

I am working on what appears to be a bug, but I am not sure where exactly.
I am creating a new date without specifying a time portion. So, hours and
seconds are equal 0.
If this date is between March 10 and March 23 (did not try all a way to the
end of March) then according to Charles a date that is sent to the server is
one day less. Any other month is not affected by this potential bug.
Anyone has any explanation?

Thanks