Then, you could keep using DateTime::Format::Strptime (with %z), or use DateTime::Format::RFC3339. For example, using the standard RFC3339 format, you could use any of T02:30:00-05:00įor the former and any of T02:30:00-06:00įor the latter. 02:30:00 -06:00 (America/Denver) After "fall back"ĭate-times should be transmitted in UTC or provide the offset from UTC of the date-time.
For one hour every year, you'll get the wrong answer due to the overlap during the DST change.Ĭould refer to both 02:30:00 -05:00 (America/Denver) Before "fall back" Time zone Currently Mountain Daylight Time (MDT), UTC -6 Standard time (Mountain Standard Time (MST), UTC -7) starts Nov. Maybe you meant to use US Mountain Time, which is identified by America/Denver (UTC-7 in winter, UTC-6 in summer). Coordinated Universal Time is 7 hours ahead of Mountain Standard Time. UTC-7h MDT UTC-6h MST UTC-7h Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec The graph above illustrates clock changes in Edmonton during 2022. Is therefore 10:00:00 -07:00 (America/Los_Angeles)ĭateTime properly converted the date-time. The correct conversion of 10:00:00 -07:00 (MST) If you have a timestamp without time zone column and youre storing timestamps as UTC, you need to tell PostgreSQL that, and then tell it to convert it to. US Pacific Time ( America/Los_Angeles) is UTC-8 in the winter, and UTC-7 in the summer.US Mountain Standard Time ( MST) is UTC-7.If you refer to this list of tz database time zones, you'll see that
But even if the date-time is in US Mountain Time, that won't always give you the right answer. I think you meant to use US Mountain Time, which is identified by America/Denver.
0 kommentar(er)
