Add time zone field to BETYdb, default to UTC

[bcow]

Should have a time zone field.

[dlebauer]

Allow any TZ on this list, or excluded daylight savings time?

Or should the values be in the format of offset from UTC (e.g. any value in [-12,12])?

[robkooper]

Keep in mind that some of the names are not unique (look at CST with 5 different definitions). Also how do want to deal with daylight savings times?

[robkooper]

The BETY web app is right now always set to CST (no daylight savings), which is -6 hours from UTC. This is set in config/application.rb: (config.time_zone = 'Central Time (US & Canada)')

[dlebauer]

Is there any argument against using ISO 8601?

It is a widely used standard format and supported by Postgres.

[robkooper]

Normal ISO is : "YYYY-MM-ddTHH:mm:ss.sssXXX"

YYYY = 0000-9999 year MM = 01-12 month dd = 01-31 days HH = 00-24 hour mm = 00-59 minutes ss.sss = 00.000-59.999 seconds.miliseconds XXX = timezone

The last part is really the trouble. This should be written using the +6:00 to indicate 6 hour offset from UTC, but this does include day light savings, which I'm not sure we want, so we should make sure we always have our time converted to z which is zulu time or UTC. Now the question becomes when I enter a time in the bety web interface what timezone do I enter it in: 1) local time to me, 2) local time to the server 3) local time to the site or 4) utc?

[mdietze]

I thought we agreed that UTC should be the default to start, and the we should add the option to specify an alternative.

[dlebauer]

ISO 8601 can be used to specify times in UTC, no?

Also, will this apply to all time fields in the database?

[bcow]

Copied over from the email I sent to the pecan-dev list:

BETY Questions:

Currently all BETY servers are hardcoded to CST - so all input dates are assumed to be in CST and then are converted to UTC and stored in the database. This explains why all my inputs (for example, NARR) have been stored with a six hour time shift from what they should be. Should the time zone of the servers be set to their local time zones respectively, or UTC?

Mike: UTC

Inputs need to specify a time zone, otherwise, should the default be UTC or site local time zone or server time zone?

Mike: Default should be UTC

When a new site is entered, it should specify a time zone (site local time) Currently this is an integer. Do we want string instead (taking into account that abbreviations are not unique- for example CST)?

Mike: No, the string is ambiguous. The integer is not

Does / should this take into account daylight savings?

Mike: Does: No Should: debatable