Hi Jeremy Thanks for the prompt response. Good to see the gem is well supported. I've been on other things since Wednesday, but should be cracking on with this from Monday.
I'm still hunting where ruby objects are converted for delivery to the jdbc layer, and I think I've just found an ideal place to detect that an MS datetimeoffset has been loaded, so I can control its conversion. After thinking about this for a while, I'm aiming to have a switch that, if enabled, handles the timestamps more formally: MS SQL date => Ruby Date => a suitable MS date literal form. As per current behaviour. MS SQL datetime (and datetime2 et al) => Ruby Time => MS SQL datetime literal As per current behaviour. MS SQL datetimeoffset => Ruby DateTime with timezone offset unchanged. Ruby DateTime => MS SQL datetimeoffset literal (basically the ISO format) It will be strict in the sense that the developers must pay more attention to using the correct Ruby classes; datetime will not be assumed to suit use for an MS datetime type once the switch is set. This would be a breaking change for many projects, so it needs to be enabled explicitly with a switch. For the application, I need a clear distinction between a Ruby Time type and the Ruby DateTime. The Ruby Time is to be used with localtime offset for server-related stamps such as schedules and audit data). The Ruby DateTime will be used to faithfully record the data that can be collected from various timezones, and needs to carry its local offset so that questions like "all data for Monday" can be easily accommodated without having to laboriously code conversions from a fixed offset and a separately stored locality indicator. I know conventional "wisdom" which is splattered all over the Internet says to convert everything to UTC, but the loss of locality information is not acceptable for this application. Ideally, the code needs to be written so that other engines with a datetimeoffset can play the same game if someone else makes the adapters. I guess my main concern is that I find all the locations in the code that marshal the objects to and from the JDBC, and that the setting can be used at the connection, db and possibly statement level as so many of the extensions and settings can. I've taken a fork, and hopefully will be ready for feedback within the next few working days. Cheers, Andrew On Wednesday, 18 July 2018 00:48:38 UTC+10, Jeremy Evans wrote: > > > Sequel doesn't really handle timezones by default, but it does ship with > fairly comprehensive support for handling them. See > http://sequel.jeremyevans.net/rdoc/classes/Sequel/Timezones.html. So I > don't think you need to write a framework to handle timezones, such a > framework already exists and works well on most databases supported by > Sequel. > > I'm not sure how good the support is for the MSSQL datetimeoffset type. > Sequel doesn't use that type by default (it uses datetime for > Time/DateTime). If there are datetimeoffset specific features that need to > be added to Sequel, I'm open to that as long as they are backwards > compatible by default. > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
