TimeRange should have values as DateTime internally

Bug #651345 reported by Manish Sinha (मनीष सिन्हा) on 2010-09-29
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zeitgeist Sharp
Fix Committed
Low
Manish Sinha (मनीष सिन्हा)

Bug Description

TimeRange should have values as DateTime internally

Internally TimeRange stores values as Int64 only. It should store as DateTime and return Int64 only when needed. Plus when Int64 value is assigned, it should convert it to DateTime.

Conversion log is already implemented in ZsUtils

Related branches

I disagree. Lets keep it all the same
python-zeitgeist = libzeitgeist = zeitgeist-sharp

On Wed, Sep 29, 2010 at 7:46 PM, Manish Sinha <email address hidden>wrote:

> Public bug reported:
>
> TimeRange should have values as DateTime internally
>
> Internally TimeRange stores values as Int64 only. It should store as
> DateTime and return Int64 only when needed. Plus when Int64 value is
> assigned, it should convert it to DateTime.
>
> Conversion log is already implemented in ZsUtils
>
> ** Affects: zeitgeist-sharp
> Importance: Undecided
> Status: New
>
> --
> TimeRange should have values as DateTime internally
> https://bugs.launchpad.net/bugs/651345
> You received this bug notification because you are a member of Zeitgeist
> Sharp, which is the registrant for Zeitgeist Sharp.
>
> Status in Zeitgeist Sharp: New
>
> Bug description:
> TimeRange should have values as DateTime internally
>
> Internally TimeRange stores values as Int64 only. It should store as
> DateTime and return Int64 only when needed. Plus when Int64 value is
> assigned, it should convert it to DateTime.
>
> Conversion log is already implemented in ZsUtils
>
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

Well, it's more of giving a more managed experience since you would expect DateTime property to expect native types for that Framework/language

Changed in zeitgeist-sharp:
milestone: none → 0.1.0b
milestone: 0.1.0b → none

Made seif agree. He was confused that the fields are public.

Changed in zeitgeist-sharp:
assignee: nobody → Manish Sinha (manishsinha)
importance: Undecided → Low
milestone: none → 0.1.0b
status: New → Confirmed

OK but rethinking it what will it bring us to have it internally? Why the
extra fuss?

On Fri, Oct 1, 2010 at 7:53 PM, Manish Sinha <email address hidden>wrote:

> Made seif agree. He was confused that the fields are public.
>
> ** Changed in: zeitgeist-sharp
> Importance: Undecided => Low
>
> ** Changed in: zeitgeist-sharp
> Status: New => Confirmed
>
> ** Changed in: zeitgeist-sharp
> Milestone: None => 0.1.0b
>
> ** Changed in: zeitgeist-sharp
> Assignee: (unassigned) => Manish Sinha (manishsinha)
>
> --
> TimeRange should have values as DateTime internally
> https://bugs.launchpad.net/bugs/651345
> You received this bug notification because you are a member of Zeitgeist
> Sharp, which is the registrant for Zeitgeist Sharp.
>
> Status in Zeitgeist Sharp: Confirmed
>
> Bug description:
> TimeRange should have values as DateTime internally
>
> Internally TimeRange stores values as Int64 only. It should store as
> DateTime and return Int64 only when needed. Plus when Int64 value is
> assigned, it should convert it to DateTime.
>
> Conversion log is already implemented in ZsUtils
>
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

There is another thing which only concerns the developers of zg-sharp - Using native data structures as much as possible. Least hardcoding of types like Int64 and UInt64 etc for which size is fixed.

Well this wasnt a big issues, more of coding guidelines.

Changed in zeitgeist-sharp:
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers