0

How do I override Flurl's default behaviour when serializing objects to query string values? E.g. the below code

DateTime date = new DateTime(2017, 1, 2, 3, 4, 5);
Url url = "http://domain.com".SetQueryParam("date", date);

produces the following url:

http://domain.com?date=01%2F02%2F2017%2003%3A04%3A05

What I want is this:

http://domain.com?date=2017-01-02T03%3A04%3A05.0000000

which would be the result of serializing the date as follows:

date.ToString("O")
Andrew
  • 1,139
  • 1
  • 12
  • 27

1 Answers1

0

Flurl takes care of URL-encoding but beyond that isn't really concerned with custom string formatting. I guess the most obvious way to do what you want is this:

"http://domain.com".SetQueryParam("date", date.ToString("O"));

If you're doing this a lot and want to avoid specifying the formatting bit every time, you could add your own extension methods (one for Url and one for string, per the pattern):

public static Url SetDateParam(this Url url, string name, DateTime date)
{
    return url.SetQueryParam(name, date.ToString("O"));
}

public static Url SetDateParam(this string url, string name, DateTime date)
{
    return new Url(url).SetDateParam(name, date);
}

Then you've got:

"http://domain.com".SetDateParam("date", date);
Todd Menier
  • 37,557
  • 17
  • 150
  • 173
  • Thanks @Tod, it's a shame Flurl does not allow to define serialization rules for various types. Even more annoying is that date serialization does not even respect the thread's current culture and is hardcoded as m/d/y. Why not the canonical y-m-d format, which is what I was trying to achieve? If I send a date in the querystring to a server running on e.g. Australian regional settings, it will try to interpret it as d/m/y and half of my dates will come out wrong. For now I decided not to use Flurl and wrote my own query string builder... – Andrew Feb 14 '17 at 23:30
  • 3
    @Andrew I question your judgement here in several regards. First, I don't find it shameful at all that a feature doesn't exist that no one's asked for until now. Did you consider logging a suggestion or submitting a PR on GitHub before complaining here? Second, I suggested 2 very simple, straightforward solutions to doing what you want with Flurl. If you read them and understand them and still concluded that ditching it and writing your own builder is your best option, then I'm afraid I don't follow your thought process. – Todd Menier Feb 15 '17 at 21:30
  • @@Todd sorry, I did not realise you were the Flurl author, and might take my comment personally. I'm not criticising the component in general, I think it's great and I had all the intentions to use it until I discovered this behaviour. The solutions you proposed will not work for me. You're saying you "don't follow my thought process", but you don't know my exact requirements. I frankly also do not follow your thought process when you decided to hardcode date serialization as m/d/y rather than use unambiguous y-m-d. Can you please explain? – Andrew Feb 16 '17 at 01:04
  • Actually Flurl use ConfigureAwait(false) internally. This does not pass Current Culture until .net 4.6. https://stackoverflow.com/questions/45530837/why-is-the-culture-kept-after-configureawaitfalse – Maly Lemire Feb 26 '18 at 16:14