Voyage, DateAndTime and UTC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Voyage, DateAndTime and UTC

HilaireFernandes
Hi,

As far as I see when I store a DateAndTime with local time,
"2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC
DateAndTime  "2017-03-31T15:10:46.137086+00:00".

Am I doing something wrong or do I need to use a mongo description to
correct that. But wait, even so, I will not know what was the initial
local time.

How do you usually deal such issue?

Thanks

Hilaire
--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Voyage, DateAndTime and UTC

NorbertHartl
Hi,

> Am 31.03.2017 um 17:16 schrieb Hilaire <[hidden email]>:
>
> Hi,
>
> As far as I see when I store a DateAndTime with local time,
> "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC
> DateAndTime  "2017-03-31T15:10:46.137086+00:00".
>
> Am I doing something wrong or do I need to use a mongo description to
> correct that. But wait, even so, I will not know what was the initial
> local time.
>
> How do you usually deal such issue?
>
it's a pitty. BSON only supports a date type which is date and time in UTC. So the offset information is stripped off and that is the reason why you get it this way. I fell over this a lot. Especially when you use a local midnight DateAndTime store it in mongo, read it and then do #asDate you will end up having one day before. Very annoying.
I think we shouldn't store DateAndTime as BSON date. We should create a custom type that includes timezone offset information.

Norbert


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Voyage, DateAndTime and UTC

Paul DeBruicker
Or just store as ISO8601 string.





NorbertHartl wrote
Hi,

> Am 31.03.2017 um 17:16 schrieb Hilaire <[hidden email]>:
>
> Hi,
>
> As far as I see when I store a DateAndTime with local time,
> "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC
> DateAndTime  "2017-03-31T15:10:46.137086+00:00".
>
> Am I doing something wrong or do I need to use a mongo description to
> correct that. But wait, even so, I will not know what was the initial
> local time.
>
> How do you usually deal such issue?
>
it's a pitty. BSON only supports a date type which is date and time in UTC. So the offset information is stripped off and that is the reason why you get it this way. I fell over this a lot. Especially when you use a local midnight DateAndTime store it in mongo, read it and then do #asDate you will end up having one day before. Very annoying.
I think we shouldn't store DateAndTime as BSON date. We should create a custom type that includes timezone offset information.

Norbert
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Voyage, DateAndTime and UTC

HilaireFernandes
Thanks for the idea.
For me it is a bug[2], like the other one related to Date persistency,
saved as DateAndTime, then shifting you one day[1].

Hilaire


[1] https://github.com/pharo-nosql/voyage/issues/88
[2] https://github.com/pharo-nosql/voyage/issues/89

Le 31/03/2017 à 18:54, Paul DeBruicker a écrit :
> Or just store as ISO8601 string.
>

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Voyage, DateAndTime and UTC

HilaireFernandes
Based on the Paul suggestion, one can write a description to get
DateAndTime right.
Hopefully this could be fixed in Voyage

Hilarie


mongoAccesstime
<mongoDescription>
^ VOToOneDescription new
        attributeName: 'accessTime';
        accessor: (MAPluggableAccessor
                read: [:userClient| userClient accessTime printString]
                write: [:userClient :string | userClient accessTime: (DateAndTime
fromString: string)]);
        yourself

Le 31/03/2017 à 21:06, Hilaire a écrit :
> Thanks for the idea.
> For me it is a bug[2], like the other one related to Date persistency,
> saved as DateAndTime, then shifting you one day[1].

--
Dr. Geo
http://drgeo.eu


Loading...