<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
06:50 banditron joined
06:57 dreinull joined
09:38 banditron joined
10:15 irclogger_com joined
10:15 Topic for
11:37 GitHub42 joined
11:37 <GitHub42> [13sequel] 15mvasin opened pull request #1345: Fix a misprint and if/unless confusion (06master...06patch-1) 02https://git.io/v9ncq
11:37 GitHub42 left
12:12 banditron joined
13:17 borsothy joined
13:18 <borsothy> hi :) is this the right place to ask a question about Sequel?
14:01 GitHub166 joined
14:01 <GitHub166> [13sequel] 15jeremyevans commented on issue #1345: Looks good, thanks for the patch! 02https://git.io/v9nV0
14:01 GitHub166 left
14:05 banditron joined
17:54 GitHub90 joined
17:54 <GitHub90> [13sequel] 15jeremyevans closed pull request #1345: Fix a misprint and if/unless confusion (06master...06patch-1) 02https://git.io/v9ncq
17:54 GitHub90 left
17:54 GitHub39 joined
17:54 <GitHub39> [13sequel] 15jeremyevans pushed 3 new commits to 06master: 02https://git.io/v9cZf
17:54 <GitHub39> 13sequel/06master 142294e93 15vermishelle: Fix a misprint and if/unless confusion
17:54 <GitHub39> 13sequel/06master 144812e44 15Jeremy Evans: Recognize additional disconnect error on MySQL
17:54 <GitHub39> 13sequel/06master 14f8ff329 15Jeremy Evans: Handle change in ActiveSupport::Duration behavior in ActiveSupport 5.1 in specs...
17:54 GitHub39 left
18:00 glennpratt joined
18:05 banditro_ joined
18:22 tercenya joined
19:00 banditron joined
19:12 tercenya joined
19:34 tercenya joined
19:47 banditron joined
19:59 banditron joined
21:49 AYGHOR joined
21:49 <AYGHOR> im havin a hard tiem finding on teh docs how to make a .where(time: CURRENT_TIME)
21:50 <AYGHOR> but using teh DB CURRENT_TIME
21:50 <AYGHOR> not my code
21:50 <AYGHOR> somebody?
21:51 <AYGHOR> i found Dataset#current_datetime
21:51 <AYGHOR> but it is not available on teh subset block =o(
21:54 <Caesium> there's a constant, Sequel::CURRENT_TIME
21:54 <Caesium> also CURRENT_DATE and CURRENT_TIMESTAMP, use whichever is appropriate for the column you're selecting against
21:55 <AYGHOR> nice!
21:56 <AYGHOR> ty!
21:56 <Caesium> np :)
22:13 <AYGHOR> hm
22:13 <AYGHOR> now
22:13 <AYGHOR> seems to be in teh future
22:13 <Caesium> :o that sounds odd :)
22:13 <Caesium> by how much :)
22:13 <AYGHOR> idk
22:14 <AYGHOR> teh query only shows CURRENT_TIMESTAMP
22:14 <AYGHOR> if i do stuff.t <= Time.now, it says false
22:15 <AYGHOR> but on DB, it says true
22:15 <AYGHOR> maybe i can select this value out of db?
22:15 <Caesium> if I do..
22:15 <Caesium> [1] pry(main)> DB.get(Sequel::CURRENT_TIMESTAMP)
22:15 <Caesium> I get
22:15 <Caesium> => 2017-04-28 23:15:13 +0100
22:15 <Caesium> which is right for my timezone :)
22:16 <AYGHOR> ies
22:16 <AYGHOR> yes
22:16 <AYGHOR> im getting stuff
22:16 <AYGHOR> at teh right tiem
22:16 <AYGHOR> => [{:now=>2017-04-28 19:16:16 -0300}]
22:16 <AYGHOR> which is pretty mch teh same value as Time.now
22:16 <AYGHOR> but
22:16 <AYGHOR> my queries are bugged
22:17 <AYGHOR> =o(
22:20 <AYGHOR> wtf is happening
22:20 <AYGHOR> Task[37].this.where {close_at <= Time.now}.count # => 0
22:21 <AYGHOR> Task[37].this.where {close_at <= Sequel::CURRENT_TIMESTAMP}.count # => 1
22:24 <AYGHOR> DB.get(Sequel::CURRENT_TIMESTAMP) - Time.now # => -0.000546429
22:24 <AYGHOR> =o(
22:24 <AYGHOR> teh db is playing with me
22:27 <Rennex> DB on a different server?
22:27 <Rennex> no, wait
22:28 <Rennex> that negative result is correct :P
22:28 <AYGHOR> its a minimal difference
22:28 <AYGHOR> i just noticed something on my db
22:28 <AYGHOR> close_at is of type timestamp without time zone
22:28 <AYGHOR> =o(
22:29 <Caesium> ah, I seem to remember reading about those.. and never to use it :)
22:29 <Caesium> iirc, it stores the information with timezone but then presents it back as GMT when you select it?
22:29 <AYGHOR> i just made my migrations with DateTime
22:30 <Caesium> with no indication as to what timezone it is in
22:31 <AYGHOR> ok
22:31 <AYGHOR> i now found that
22:31 <AYGHOR> SELECT close_at FROM tasks WHERE id = 37;
22:31 <AYGHOR> gives me
22:31 <AYGHOR> 2017-04-28 20:54:07.456606
22:31 <AYGHOR> but
22:32 <AYGHOR> 2017-04-28 22:32:44.727579+00
22:33 <AYGHOR> it gets converted to localtime on DB.get()
22:33 <AYGHOR> but doesnt on DB
22:33 <AYGHOR> and my db stuff is being stored on my localtime
22:33 <AYGHOR> without a timezone
22:34 <Caesium> I hate timezones so much :)
22:34 <AYGHOR> bad, bad db
22:34 <AYGHOR> or perhaps, bad sequel?
22:34 <AYGHOR> should it account for this?
22:35 <AYGHOR> should it store timestamps on utc?
22:36 <AYGHOR> it would make a lot of sense imho
22:37 <Caesium> hmm, there's some options you can set to determine some behaviour
22:37 <Caesium> http://sequel.jeremyevans.net/rdoc/classes/Sequel/Timezones.html
22:38 <Caesium> application_timezone might be what you want
22:38 <Caesium> try :local ?
22:38 <Rennex> imo everything should be in the local timezone, unless explicitly told to add timezones to the mix
22:38 <jeremyevans> AYGHOR: Sequel.default_timezone = :utc # if you want UTC
22:38 <bougyman> imo everything should always be UTC
22:38 <bougyman> and the presentation layer should handle the timezone wrangling
22:39 <bougyman> postgres, at least, always stores it internally as utc anyway.
22:39 <jeremyevans> bougyman: that makes sense if you deal with people in multiple timezones. However, if all users of the app are in a single timezone, it's certainly easier to use local time.
22:39 <Rennex> bougyman: probably a good rule of thumb for international shit. however, a massive pain and endless source of errors if you only really care about the local timezone :)
22:39 <AYGHOR> asd
22:39 <bougyman> Rennex: i've never seen that case.
22:39 <jeremyevans> bougyman: PostgreSQL only stores timestamps in UTC if you use timestamptz, not if you use timestamp
22:39 <AYGHOR> problem is my db is on utc and application on localtiem
22:39 <bougyman> that is, all users of an app being in one timezone everytime you use it.
22:40 <bougyman> jeremyevans: I thought timestamp was also stored internally as utc?
22:40 <AYGHOR> sequel doesnt detect this
22:40 <AYGHOR> automatically
22:40 <AYGHOR> it says it doesnt pay much attention to tiemzones anyway
22:40 <jeremyevans> bougyman: most of my apps are only used by users in a single timezone
22:40 <bougyman> yes but what if they fly to NYC?
22:41 <Rennex> bougyman: i live in a country that spans only 1 timezone and has a unique language, so timezones are never an issue here unless i make something truly international :)
22:41 <jeremyevans> bougyman: then they are probably still going to want to know an application was submitted in pacific time, not in eastern time :)
22:41 <Caesium> Rennex: what about summertime?
22:41 <bougyman> that's why I think it belongs in the presentation layer
22:41 <AYGHOR> and teh living is easy?
22:41 <Caesium> that's basically another timezone once a year :)
22:41 <Rennex> Caesium: yep. summertime sadness :/
22:42 <AYGHOR> fish are jumping
22:42 <AYGHOR> and teh cotton is high
22:44 <Rennex> AYGHOR: i'm thinking more like: i'm feeling electric tonight
23:01 <Freaky> if only Swatch Time had caught on ;)
23:19 <AYGHOR> =O3
23:19 <AYGHOR> ty all <3
23:51 tercenya joined