Dates

[DAZ]

Hi,

The docs say the following date types are available:

DateTime, Date, Time

I have always just used DateTime, but would actually like to work in
seconds and therefore use a Time object.

Is there any difference in the background in using Time as a type?

e.g.:

property :created_at, Time, :default => proc { |m,p| Time.now}

cheers,

DAZ

[Michishige Kaito]

The differences lie in the Ruby types you'll be working with, as the types
correspond with Ruby date and time classes. I suggest you have a look at
their documentation and judge by yourself.

As far as I'm concerned, DateTime has support for timezones and some other
fancy things, while both Date and Time are a little "simpler". Depends on
your needs. I usually just use Date or Time.

[DAZ]

Thanks for the reply Michishige. I understand the differences between
the 3 Ruby date types, but wondered what DM did behind the scenes with
these ... are there any differences in how they are saved in the
underlying DB?

DAZ

[Martin Gamsjaeger]

DAZ,

Have a look at:

https://github.com/datamapper/dm-migrations/blob/master/lib/dm-migrations/adapters/dm-do-adapter.rb#L284-286

Note that this is the "base" behavior. Other adapters in that folder may or may not overwrite these defaults, based on the respective datastore's abilities.

cheers

snusnu

--
You received this message because you are subscribed to the Google Groups "DataMapper" group.
To post to this group, send email to datam...@googlegroups.com.
To unsubscribe from this group, send email to datamapper+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.

[Michishige Kaito]

I think they are all stored as native date/time types, depending on
database support. Either that, or strings that are parsed back to Date
objects. Have a look at the data_objects code for your database, to
confirm this behavior. I don't think this will be much of a constraint,
however, unless you're dealing with billions of records. In smaller apps,
the main constraint is programming time and comfort, which is why I was
talking about the Ruby types =)

On Sat, 16 Apr 2011, DAZ wrote:

> Thanks for the reply Michishige. I understand the differences between
> the 3 Ruby date types, but wondered what DM did behind the scenes with
> these ... are there any differences in how they are saved in the
> underlying DB?
>
> DAZ
>
> On Apr 16, 3:49�pm, Michishige Kaito <chris.webs...@gmail.com> wrote:
>> On Sat, 16 Apr 2011, DAZ wrote:
>>> Hi,
>>
>>> The docs say the following date types are available:
>>
>>> �DateTime, Date, Time
>>
>>> I have always just used DateTime, but would actually like to work in
>>> seconds and therefore use a Time object.
>>
>>> Is there any difference in the background in using Time as a type?
>>
>>> e.g.:
>>
>>> �property :created_at, � Time, :default => �proc { |m,p| Time.now}
>>
>>> cheers,
>>
>>> DAZ
>>
>> The differences lie in the Ruby types you'll be working with, as the types
>> correspond with Ruby date and time classes. I suggest you have a look at
>> their documentation and judge by yourself.
>>
>> As far as I'm concerned, DateTime has support for timezones and some other
>> fancy things, while both Date and Time are a little "simpler". Depends on
>> your needs. I usually just use Date or Time.
>

[DAZ]

Ah yes, that's useful to know. Thanks Michishige. And thanks for the
link Martin. This should allow me to make a sensible choice about
which format to use.

cheers,

DAZ

On Apr 17, 2:20 pm, Michishige Kaito <chris.webs...@gmail.com> wrote:
> I think they are all stored as native date/time types, depending on
> database support. Either that, or strings that are parsed back to Date
> objects. Have a look at the data_objects code for your database, to
> confirm this behavior. I don't think this will be much of a constraint,
> however, unless you're dealing with billions of records. In smaller apps,
> the main constraint is programming time and comfort, which is why I was
> talking about the Ruby types =)
>
>   On Sat, 16 Apr 2011, DAZ wrote:
>
>
>
>
>
>
>
> > Thanks for the reply Michishige. I understand the differences between
> > the 3 Ruby date types, but wondered what DM did behind the scenes with
> > these ... are there any differences in how they are saved in the
> > underlying DB?
>
> > DAZ
>

> > On Apr 16, 3:49�pm, Michishige Kaito <chris.webs...@gmail.com> wrote:
> >> On Sat, 16 Apr 2011, DAZ wrote:
> >>> Hi,
>
> >>> The docs say the following date types are available:
>

> >>> �DateTime, Date, Time

>
> >>> I have always just used DateTime, but would actually like to work in
> >>> seconds and therefore use a Time object.
>
> >>> Is there any difference in the background in using Time as a type?
>
> >>> e.g.:
>

> >>> �property :created_at, � Time, :default => �proc { |m,p| Time.now}

[kilian....@gmail.com]

Hi,

I am new to DataMapper, trying it out with sqlite3.

I declared a property as

 property :created_at, Time, :default => lambda {|r,p| Time.now }

What confuses me is that the created_at property ends up
in the db as '2013-09-29T12:14:09.074859+02:00', but when
I access it from ruby, I get a truncated Time object:
2013-09-29 00:00:00 +0200

Can someone explain? Is this a bug?

See below for a list of installed gems.

Best,
Kilian

dm-aggregates (1.2.0)
dm-constraints (1.2.0)
dm-core (1.2.1)
dm-do-adapter (1.2.0)
dm-migrations (1.2.0)
dm-serializer (1.2.2)
dm-sqlite-adapter (1.2.0)
dm-timestamps (1.2.0)
dm-transactions (1.2.0)
dm-types (1.2.2)
dm-validations (1.2.0)
dm-sqlite-adapter (1.2.0)
do_sqlite3 (0.10.13)
sqlite3 (1.3.8)

[postmodern]

I think you want a DateTime property instead?

--

You received this message because you are subscribed to the Google Groups "DataMapper" group.

To unsubscribe from this group and stop receiving emails from it, send an email to datamapper+...@googlegroups.com.

To post to this group, send email to datam...@googlegroups.com.

Visit this group at http://groups.google.com/group/datamapper.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Blog: http://postmodern.github.com/
GitHub: https://github.com/postmodern
Twitter: @postmodern_mod3
PGP: 0xB9515E77

[Kilian Sprotte]

Hi,

thanks for replying! I will try DateTime. I do not really understand the solution, though. If I had tried to use Date, ok, but shouldn't Time work equally in this respect to DateTime?

Best
Kilian

> You received this message because you are subscribed to a topic in the Google Groups "DataMapper" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/datamapper/d5cLJXAznuQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to datamapper+...@googlegroups.com.

[kilian....@gmail.com]

Hi,

the concern of a truncated Time does not occur with postgresql, only with sqlite3 (I have only tried the 2 so far).

Best,
Kilian

[christian]

sqlite3 is anyways different since it just stores a 'string' as date or datetime the latter including millis and nanos. but any(?) other database just has a precision up to seconds. I personaly use Date and DateTime with UTC timezone when storing them in a database.

just my thoughts . . .

-christian

[Kilian Sprotte]

Hi! Still strange with sqlite3 to see the string '2013-09-29T12:14:09.074859+

02:00' in the db and to get a Time 2013-09-29 00:00:00 +0200. Should this be reported as a bug?

[christian]

yes that is a bug ;)