Hi Philipp,
I don't think you've understood my question properly.
My question was not about storing the date (UTC is just fine), but
about showing the date to the user, and getting that date back from
an input of that specific user.
The problem is that for now the input is in UTC, the display is in
UTC and the saving in the repository is in UTC.
Since my users would be in Japan, I would like to have then input the
dates in Japanese time. (Although, we may also want to enable them to
input the time for a different timezone. For example, a news release
that needs to be pushed up by a Japanese company on a US site at a
certain US time without the need for the user to convert back and
forth to Japanese time. But this is pushing things a bit far for now )
I see the best option would be to have a timezone setting for the
user (along language ...) and then we fix up the dates according to
that setting.
What do you think ?
Niko,
PS: see also my comments below ...
On Jun 7, 2006, at 6:54 PM, Philipp Bracher wrote:
Since most of our customers here are in Japan, it make little
sense of having them to think back and forth in UTC.
But I remember it was done for some reason ?
The intention was to store the date without a timezone (therefore
using UTC)
Yes agreed.
If you render a so stored date you just use UTC.
DateFormatUtils.formatUTC() does this for example. Well this is the
easiest approach for content.
No, I don't think users don't want to see and input their time in UTC.
Would it be possible to put a default timezone somewhere for input
dates ?
Hm, maybe we can enhance the date control so that you can define if
you like to store using the local timezone (not sure if we get
problems with the SaveHandler then)
Storage as you said should be in UTC.
I remember working on a conference booking system and had all
those troubles with booking a conference when the server was in a
timezone, the guy booking the conference was in another one, and
the actual conference was taking in another timezone :D Good fun.
This is exactly the reason why I think the dates stored in content
(dialogs) should get stored without any timezone
Yes.
Solution for scheduled activation:
- get the date (stored with UTC as usual)
- manipulate the date so that it fits to the current timezone
Here, we may need to discuss on what the 'current' timezone is. (See
example above: if the admin instance is in Japan, and the public site
is in the US, or US time)
- pass this 'corrected' date as an attibute to the workitem
Yes.
--> editors don't have to care about the timezone
well ... not sure about that one if you consider magnolia as a
professional publishing solution. Some publishers have to get their
data (articles, news) showing at a precise date and time. A press
release for example, should be published at a really precise time and
this is timezone dependant.
--> the date is stored using UTC
yes.
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
