Through the env-object for the method launch, we can set a TZ environment variable to affect the timezone of the browser. This is confirmed by an issue, where one explicitly mentions that.
I'm taking a screenshot of this page which shows a Google calendar. Setting puppeteer's TZ to US/Eastern yields times two hours later. Setting TZ to Brazil/East yields the correct US/Eastern time.
What am I missing here?
The machine timezone is actually set to UTC:
$ date
Fri Nov 30 17:09:55 UTC 2018
Related
My Gerrit version is 3.1.2 and my timezone is
I have a change that created at 2020-05-07 21:27 and merged at 2020-05-07 21:32. Then I try to search this change.
I search by condition before: 2020-05-07 23:59:00 and cannot find this change.
I search by condition before: 2020-05-08 00:01:00 and this change was found.
Is there any idea about this issue or anyway to report this issue to Gerrit?
Thanks
I found the problem and share it. According the Gerrit document page: https://gerrit-review.googlesource.com/Documentation/user-search.html
🔗 before:'TIME'/until:'TIME'
Changes modified before the given 'TIME', inclusive. Must be in the format 2006-01-02[ 15:04:05[.890][ -0700]]; omitting the time defaults to 00:00:00 and omitting the timezone defaults to UTC.
Since the gerrit use the timezone as UTC, I need to add the time as [ -0700]. For example, if my timezone if UTC +4 hour, I need to search as
before "2020-05-07 21:40:00 +0400" and this issue will be solved. Please note that the " is required.
Thanks
I'm having a frustrating issue that I can't seem to narrow down. I have searched many similar articles but they are not close enough to my issue to resolve. I am trying to pull a time from the database and display it in more than one time zone. My Rails app is using UTC as default. Here is what I'm doing:
On the create action I take the string of time which will be saved in the time column in my DB:
params[:schedule][:start] = "09:00"
Time.zone = "Central Time (US & Canada)"
#schedule.start = Time.zone.parse(params[:schedule][:start])
The above formats the time as it is supposed to:
2016-04-12 09:00:00 -0500
This is saved in the DB as:
2000-01-01 14:00:00
This has no time offset which is fine since I know it's in UTC. The problem happens when I go to display the time:
#schedule.start.in_time_zone("Central Time (US & Canada)")
This returns:
Sat, 01 Jan 2000 08:00:00 CST -06:00
Now, since this is a time column, I don't care about the date. I plan on formatting the value to only show the time. However, it is showing CST when it is currently CDT.
I can't figure out why this is happening. As I said I am not setting the Time Zone anywhere in my application.rb or anywhere else and I only set the Time zone on the create action which should be fine when moving to a new action.
Any help on clarifying this would be awesome!
This seems to be because when the time is stored it is stored with the date in the year 2000-01-01 which seems to be why it is using CST. How can I ignore the date when converting it to a particular timezone or will I need to change the column type to DateTime to get this to work properly?
It is showing CST simply because the time is read from the database including the stored date, i.e. it's read as 09:00 of Jan 1st 2000.
I guess you'd have to parse the time upon reading the attribute back. You can use a helper method in your model, for example:
# schedule model
def start_in_zone(zone)
self.start.strftime("%H:%M").in_time_zone(zone)
end
This will take only the hours and minutes part of the stored time and parse it in the given time zone with the date set to today. See this example:
"Sat, 01 Jan 2000 08:00:00".to_time.
strftime("%H:%M").
in_time_zone("Central Time (US & Canada)")
# => Tue, 12 Apr 2016 08:00:00 CDT -05:00
The fact that it matters whether it's CST or CDT means you do, on some level, care about the date. While I'm not familiar with the exact rules of Daylight Savings in that region, I do know that Jan 1 is the middle of winter and will definitely not be on Daylight Savings time.
Add the relevant date into your #schedule before putting it into a time zone, and it should fix the problem.
I have a JSON method which is returning a UTC DateTime I am storing on the server. It returns the following:
/Date(1394155885817)/
I'm trying to figure out how to get Moment JS to show me the local (browser) time. So my timezone is -5 (EST) I'd want to see 3:31 instead of 8:31. See the fiddle below.
http://jsfiddle.net/R9UbS/
What am I doing wrong here? How can I force Moment to return local?
I just ran the fiddle in Romania and got 3:31. Also, javascript's Date constructor handles UTC millis correctly. You're getting 8:31 which makes me think it's doing what it's supposed to do, showing the local time. Why is 8:31 incorrect? And is your device's timezone set correctly? (Btw if your timezone is GMT -5 then you would indeed get 8:31 PM the previous day)
Just to put this a bit in perspective, i put the number in a milliseconds to time converter and i saw that 1394155885817 actually means Fri Mar 07 2014 1:31:25 AM in UTC (or GMT for convenience) - subtracting 5 hours from this would result in Fri Mar 06 2014 8:31:25 PM
I'm a bit confused about timezones in rails. I want my rails app to use British Summer Time (like daylight savings in the US) for the timestamps set in updated_at and created_at in my models. I changed my environment.rb to say
config.time_zone = 'London'
The ubuntu server my app is on seems to use BST for it's time: in the command line, for example, if i type 'date' i get the current time (not offset by an hour). In the rails console, i see the following:
>> time = Time.now
=> Wed Oct 27 16:29:17 +0100 2010
>> time.zone
=> "BST"
All fine. However, if i make a new AR model object and save it, the timestamps are from an hour ago. So, it looks like this is using UTC. Now, i can see the logic in this: since the timestamps might be used in the model logic, you want them to be based on an unvarying yardstick time, ie UTC. But, this is a weird bit of behaviour that i don't understand:
#change a record and save it
>> someobj.save
=> true
#object's updated_at is one hour ago
>> someobj.updated_at
=> Wed, 27 Oct 2010 15:34:22 UTC +00:00
>> Time.now
=> Wed Oct 27 16:34:31 +0100 2010
#however, Time.now - object's updated at is just a few seconds.
>> Time.now - someobj.updated_at
=> 15.305549
So, before doing the subtraction, updated_at is converted into the current time zone.
The reason i want to show the date in the current time zone is just for status reports etc in the views: if someone updates something i want them to see that it was updated '1 minute ago' not 'one hour ago'.
Can anyone unconfuse me? cheers, max
EDIT: My immediate problem, of showing the right time in the status, is solved by using the 'time_ago_in_words' helper, which adjusts for time zone. I'd still like someone to explain what's going on with the timestamps though :)
Timestamps are stored in UTC by default, and this is probably the best way to do it. If you move from one server environment to another, you don't want all of your times shifting around just because you switched time zones.
If you want to know what the timestamp is in your local time zone, you just have to ask for it that way:
someobj.updated_at.localtime
Note the offset listed at the end of the times -- the first offset is 0, the second is 1. When the time calculation occurs, the offset is included automatically, so that the subtraction gives you the correct result. someobj.updated_at and Time.now each displays its value in a different time zone, so they are really only 9 seconds apart, not 1 hour and 9 seconds.
For some reason times are appearing differently in development (my local Mac) and production (Heroku). Take a look: (Just prior to doing this I did a heroku db:pull, so the databases should be identical)
Production (Heroku)
>> Annotation.last.id
=> 2028
>> Annotation.last.created_at
=> Sat, 12 Sep 2009 06:51:33 UTC +00:00
>> Time.zone
=> #<ActiveSupport::TimeZone:0x2b4972a4e2f0 #tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, #utc_offset=0, #name="UTC">
>> Time.now.zone
=> "PDT"
Development (my Macbook Pro)
>> Annotation.last.id
=> 2028
>> Annotation.last.created_at
=> Sat, 12 Sep 2009 09:51:33 UTC +00:00
>> Time.zone
=> #<ActiveSupport::TimeZone:0x23c92c0 #tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, #utc_offset=0, #name="UTC">
>> Time.now.zone
=> "EDT"
Since the created_at times differ by 3 hours, I assume this is related to the 3 hour difference between EDT and PDT, but I'm not sure what's going on.
EDIT: Here's what the raw data looks like:
sqlite> Select created_at from annotations where id = 2028;
2009-09-12T09:51:33-04:00
It looks like this is a problem when moving databases between Heroku and your development machine. Running the SQL query directly gives me this:
Local: {"created_at"=>"2009-10-30 22:34:55.919586"}
Remote: {"created_at"=>"2009-10-31 01:34:55.919586"}
Same problem, exactly a three hour shift. Looking through the source for Taps, the Gem heroku uses for DB sync, does not provide any clues into what could be going wrong here. I've opened a heroku support ticket, and I'll update this post with what I find.
UPDATE:
Ricardo and Morten from Heroku replied. Specify the TZ on the command line like so:
TZ=America/Los_Angeles heroku db:pull
Looks like it assumes the dates in the DB are stored in your local time-zone which is different for the 2 environments and then it translates it to UTC. since the value in DB is essentially the same you get 2 different UTC values.
What is the value of config.time_zone from your "config/environment.rb"?
Also what is the value of "Select created_at from annotations where id= 2028" ?
This is a problem I've encountered before as well.
If you do something like Annotation.last.created_at on the rails console, the result already has the timezone applied to it. You should look at the "pure" date in mysql, via the mysql console :-)
Perhaps one or both of the machines has it's system time setting set to local timezone, instead of UTC. If that's the case, then it would be confused on what value the UTC time (int) actually is.
There are a number of areas to check on both machines:
system timezone
local(user) process timezone
database system timezone
database local timezone
This doesn't seem explicable by one or the other reporting its local time as the UTC time: Eastern time is 4 hours away from UTC, and Pacific time is 7 hours away, but you're seeing a three-hour difference, not a 4- or 7-hour difference.
It seems like both of them are producing incorrect output. SQLite is clearly saying that the 09:51 time is supposed to be an -04:00 time, i.e. Eastern time, but Rails is incorrectly claiming that it's UTC in one case — and in the other case, it's translating it from Eastern to Pacific, then incorrectly claiming that the result is UTC.
Maybe this is a bug in the SQLite backend for ActiveRecord? Because it seems like the kind of thing that would have been caught and squished long ago if it were in widely-used code.