[Neos] Neos DateTime handling

[Rens Admiraal]

Ok, storing UTC has advantages. And we currently don't do that (the 
original timezone is actually stored in the node properties if I read 
that correctly).

Just a question that comes to mind: if we store UTC in the database and 
a server has a timezone offzet -6, how does that affect for example the 
fetching of nodes and also taking the start / stop time into account?



Adrian Föder schreef op 19/03/14 19:17:
> You all might know me as the "timezone addict", so yes: I fully agree in
> storing time as UTC and rendering it as appropriate.
>
> In my own app I even fetch the user's time zone via JavaScript because
> this contains the system's time.
>
> But still: store UTC!
>
> Am 18.03.2014 22:11, schrieb Dominique Feyer:
>> Intersting discussion on this topic on StackOverflow:
>> http://stackoverflow.com/questions/10834665/how-can-i-handle-time-zones-in-my-webapp
>>
>>
>> For my point of view, timezone is a user parameter (user preference or
>> auto detection is an other story), but always storing in UTC make a
>> lots of sense.
>>
>> My two cents ;)
>>
>> --
>> Dominique Feyer
>> Sent with Airmail
>>
>> Le 18 mars 2014 à 21:30:04, Rens Admiraal (rens.admiraal at typo3.org) a
>> écrit:
>>
>> Hi all,
>>
>> Today I played around with the datepicker so see how the time / datetime
>> capabilities work. It seems to work pretty awesome, you can for example
>> create a timepicker by using the following config:
>>
>> time:
>> type: date
>> ui:
>> label: 'Some Time'
>> inspector:
>> editorOptions:
>> format: 'h:ii'
>> group: 'someGroup'
>>
>> Or date + time picker by using:
>>
>> dateAndTime:
>> type: date
>> ui:
>> label: 'Some Date with Time'
>> inspector:
>> editorOptions:
>> format: 'dd-mm-yyyy h:ii'
>> group: 'someGroup'
>>
>>
>> As you can see, just setting the format is enough. *BUT* we do have an
>> issue here. As the original datepicker did only support dates we
>> hardcoded the transfer format between the client and server in:
>> 'yyyy-mm-dd'. This is done in the DateTimeEditor (js),
>> ContentElementWrappingService (Neos) and NodeConverter (CR). This causes
>> the time information to get lost on storage, so we need to fix that in
>> some way.
>>
>> I played around with the code and come up with:
>> https://review.typo3.org/#/q/status:open+branch:master+topic:datetime,n,z
>>
>> I tried to use the \DateTime::ISO8601 constant, but that one adds an
>> offset which causes troubles on the client side at the moment. So I used
>> the ISO8601 format without offset.
>>
>> But before digging too deep it might make sense to step back a little
>> and decide how we want to handle timezone differences between server and
>> client and so on.
>>
>> Do you have any thoughts on that?
>>
>> Greetz,
>> Rens
>> _______________________________________________
>> Neos mailing list
>> Neos at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/neos
>>
>