[FLOW3-general] DateTime limited to Unix timestamp?

[Michael Sauter]

Hi,

On 01.07.10 19:13, Martin Kutschker wrote:
> But that's not the only reason why you want to store date/time objects in a different format.
>
> I'm not sure if I can store arbitrary objects in the DB in FLOW3 (in Extbase you can not), but let's
> assume for now we can then I think there could be different date/time objects that behave like a PHP
> DateTime but persiste differently. Or there is a special annotation that let's you choose between
> different storage formats.
>
> timestamp (Unix epoch), eg 1278003973
> string (yyymmddThhmmss#oooo), eg 20040212T151921+0000
> tzstring (yyymmddThhmmss(oooo)), eg 20040212T151921(0000)
>
> "string" and "tzstring" differ in the way the time zone is handled. "string" uses a regular
> approach, to get the UTC date/time you must add the offset. With "tzstring" the date/time *is* in
> utc, the offset denotes only the TZ used when entering the TZ (which makes it possible to sort the
> field in the DB.

What exactly is the problem here when using a timestamp only? A 
timestamp is by definition "seconds since 1.1.1970 00:00 in UTC". When 
you have a timezone attached to your DateTime object, the conversion to 
a timestamp will take the timezone into account. This means all 
persisted "dates/times" are in UTC, which is perfectly fine. All you 
need to do is to store the timezone as well (another property of the 
model) so you can output your date in the timezone you want. Storing the 
dates in the same timezone (same format) also enables you to do queries 
(comparing dates) a lot easier ... the timezone information is pretty 
useless there, no?
(Again, see my follow-up post on this: 
http://michaelsauter.net/blog/2010/04/22/travelling-through-date-and-time-part-iii/ 
... sorry for linking to my blog all the time ;))

> If you want it more verbose we could add also this
>
> iso8601, eg 2004-02-12T15:19:21+00:00
>
> Though the support of microseconds in DateTime is far from optimal you might want to have also
> format for that.

Dunno if storing microseconds is something you would want, but you could 
still do this with timestamps as well (you would have to store the 
microseconds separately, similar to the timzone handling, and update the 
DateTime object upon recreation of the model).

So I don't see why you would want the possibility to have different 
storage formats? IMHO timestamps are all you'll need. Maybe except dates 
prior to 1970, but it is not that complex to implement your own handling 
in the model (like storing custom strings for example and build your 
date by hand, but then again you might need to take all  historic 
timezones and stuff into account and I don't know if you would want to 
do that :D)

Or maybe you had some other case in mind?

~michael