Jay Pipes wrote:
> Hi all!
>
> A while ago, the list discussed removing timezones from the server and
> met with little resistance from folks.
>
> So, some work went in to removing timezones from the server.
>
> However, for reasons I won't go into here, timezones are still present
> in the server and are causing, let us say, a bit of a headache. If we
> can fully commit to getting rid of timezones, I think I can dramatically
> improve the simplicity of how time and dates are handled in the server.
>
> Questions for everyone:
>
> 1) What do people think about changing the prescribed behaviour of
> FROM_UNIXTIME() and UNIX_TIMESTAMP() to *not* take into account the
> system time zone? Currently, even though we don't support time zones,
> for some reason, we're currently accounting for the system time zone in
> these functions. I can't really understand why, and it's causing bugs. :)
I don't think we should do anything special (of our own) to account for
the system time zone. If we decide to do that, we should use localtime()
or some other call that lets all of the system info about that do the
right thing.
I am very torn about what's right here. I think totally punting on local
timezone will come across as lame. I think we should _always_ store in
UTC like we talked about... but knowing when and how to convert things
so that it makes sense is tricky - and I'm not convinced that no
conversion makes it any less odd or tricky for the user.
If I do:
insert into t1 (timecol) values (now());
select timecol from t1;
What should I see?
What if I also had a php app doing
"insert into t1 (timecol) values ("+now()")";
Into the same table. Shouldn't that work properly in a cloud? In fact,
if I've got ntp and all set up properly in my large-scale environment,
shoudn't I expect now() on drizzle to make now() in the other parts of
my system?
However, to re-iterate, I do not think that drizzle needs a timezone
config value itself. The system timezone is fine.
> 2) What do people think about adding microsecond to the TIMESTAMP data
> type by default? This would require 4 more bytes of storage per row.
Yes.
> 3) What do people think about *removing* the current behaviour of
> outputting a microsecond time for DATETIMEs with all 0's? Personally,
> I've always found this strange considering MySQL ignores (for storage)
> the microsecond time part. We would add a microsecond display to
> TIMESTAMP.
Yes.
> Thoughts?
>
> -jay
>
> _______________________________________________
> Mailing list: https://launchpad.net/~drizzle-discuss
> Post to : [email protected]
> Unsubscribe : https://launchpad.net/~drizzle-discuss
> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
