ryanstout
commented
9 years ago This looks great. Thanks so much for the hard work on it. I have a few thoughts if thats cool, let me know if I'm missing something or you have a different idea:
- I think since people are going to be using this to replace the Time class, it might make since to make it
::VoltTimeinstead ofVolt::VoltTime(though I'm open either way) - So part of my idea with VoltTime was to have it where VoltTime is always in UTC. It looks like you have it where it can be local or UTC. (thought I might have read it wrong) I think having VoltTime be essentially "timezoneless" would be a big selling point, because its just a point in time, and its only when you go to print it or parse a VoltTime (or create one) that it needs to worry about timezones. Maybe it would make since to change getlocal to be private, or change it to be "get_ruby_time_in_local" or something (so its longer so people know its not part of the normal workflow). I personally find a lot of my issues with timezones come when converting between different timezones and doing some operations. So the idea with VoltTime would be it gets converted to UTC when it comes in, and gets converted out of UTC when it goes out. But its always UTC when its in VoltTime (when your working with it)
- You have a
to_skkkjmethod, looks like a typo for to_s :-) - Does it make since to add a .from_now option to Numeric? (I use that a lot in rails)
- It would be nice to have
in_zone_strftime(and similar,in_zone_month/day/year/etc..(offset)) methods, so the user could pass in a timezone when needed and get the value based on that timezone. Not sure how hard that would be to make work on the client, but I expect it to be used more on the server (for rest api's maybe or something?) - On the server, Volt::Time.localstrftime for example uses .getlocal, but getlocal on the server returns the local timezone set on the server. I think 99% of the time this isn't going to be what people want in volt. Your probably going to want it to either 1) raise an error saying you can't use local on the server because it doesn't know the persons timezone. (and saying they should use in_zonestrftime(..) or something) or 2) we could use the meta data on tasks to pass in the timezone from the client, so we could answer the request in the users local timezone. (And in the case they use local when not being called from a task, it would raise an exception)
Sorry for the big list of comments. I'm really excited about this stuff and I think this could make time handling a lot easier for everyone. Feel free to hit me up on gitter with thoughts/questions. Again, great work, thanks for all of the time you put into this :-)
VoltTime helper with duration support and other time calculations.