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)
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.
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)
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
Solution for scheduled activation:
- get the date (stored with UTC as usual)
- manipulate the date so that it fits to the current timezone
- pass this 'corrected' date as an attibute to the workitem
--> editors don't have to care about the timezone
--> the date is stored using UTC
OK?
Regards,
Philipp Bracher
obinary ltd.
-----------------------------------------------------
[EMAIL PROTECTED] http://obinary.com
magnolia content management http://magnolia.info
-----------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
