Jump to content

Recommended Posts

Posted

Looks like FieldtypeDatetime currently ignores timezone issues?

Seems like this needs to be addressed somehow, at some point - it's fine if your applications are used in one timezone exclusively, or if users are aware that all timestamps are in ET say, but it seems this is going to be inadequate for applications used even across multiple timezones in the US, which most US applications probably are.

This problem is particularly serious if you're storing dates only - since, without timezone information, a single date actually spans a 48-hour period worldwide. You can't really convert dates if you don't have a time.

I would strongly prefer to have all timestamps stored in UTC in the database - with the ability to auto-detect a default timezone for anonymous users, and selecting a timezone for registered users. Anything like that already in the pipeline?

  • Like 3
Posted

I agree that we'll want a UTC-based date fieldtype at some point. Though this is the first that it's come up, so I think that most folks (including me) aren't using the Datetime field in situations where timezone matters. Most usage has to do with dates accompanying content that is specific to server time, in the same way that the built-in created/modified timestamps are. But as the use of PW increases for things involving authenticated users and storage of their data, I think there will be demand for something like this. 

  • Like 2

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...