Dates

31 views
Skip to first unread message

DAZ

unread,
Apr 16, 2011, 10:06:50 AM4/16/11
to DataMapper
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

unread,
Apr 16, 2011, 10:49:43 AM4/16/11
to DataMapper

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

unread,
Apr 16, 2011, 11:05:21 AM4/16/11
to DataMapper
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

unread,
Apr 16, 2011, 11:28:47 AM4/16/11
to datam...@googlegroups.com
DAZ,

Have a look at:


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

unread,
Apr 17, 2011, 9:20:05 AM4/17/11
to DataMapper
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

unread,
Apr 17, 2011, 1:51:53 PM4/17/11
to DataMapper
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

unread,
Sep 29, 2013, 6:25:07 AM9/29/13
to datam...@googlegroups.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

unread,
Sep 29, 2013, 6:33:24 PM9/29/13
to datam...@googlegroups.com
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

unread,
Sep 30, 2013, 7:17:25 AM9/30/13
to datam...@googlegroups.com

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

unread,
Sep 30, 2013, 9:58:48 AM9/30/13
to datam...@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

unread,
Sep 30, 2013, 10:12:43 AM9/30/13
to datam...@googlegroups.com, kilian....@gmail.com
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

unread,
Sep 30, 2013, 10:19:23 AM9/30/13
to datam...@googlegroups.com
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

unread,
Sep 30, 2013, 10:55:13 AM9/30/13
to datam...@googlegroups.com
yes that is a bug ;)
Reply all
Reply to author
Forward
0 new messages