Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 21 21:26
    jskeet closed #1610
  • Jan 21 21:26
    jskeet commented #1610
  • Jan 21 21:24
    jskeet commented #1610
  • Jan 21 21:21
    mr-russ opened #1610
  • Dec 29 2020 18:58

    jskeet on master

    Update CONTRIBUTING.md (compare)

  • Dec 29 2020 08:48

    jskeet on master

    Fix typo in commandline readme Note the use of bash for scripts (compare)

  • Dec 29 2020 08:48
    jskeet closed #1609
  • Dec 29 2020 08:48
    jskeet opened #1609
  • Dec 29 2020 08:47
    jskeet commented #1182
  • Dec 29 2020 03:59
    matkoch commented #1182
  • Dec 29 2020 03:42
    matkoch commented #1182
  • Dec 29 2020 03:42
    matkoch commented #1182
  • Dec 29 2020 00:02
    jskeet commented #1182
  • Dec 28 2020 23:54
    eatdrinksleepcode commented #1182
  • Dec 28 2020 23:46
    eatdrinksleepcode commented #1182
  • Dec 28 2020 18:00
    matkoch commented #1182
  • Dec 28 2020 17:58

    jskeet on master

    Point at global.json to indicat… (compare)

  • Dec 28 2020 17:58
    jskeet closed #1608
  • Dec 28 2020 17:57
    jskeet opened #1608
  • Dec 28 2020 17:54
    jskeet commented #1182
Jon Skeet
@jonskeet_twitter
No, that's using UTC, which I assume is not what you're after. I suspect you want startLocalDate.AtStartOfDayInZone(tz) etc. If that's not what you're interested in, please ask a question on Stack Overflow with an example of what you're trying to do. (Note that startLocalDate.PlusDays(1) is a simpler way of getting the next day.) It's odd that your start is after your end though...
Håvar Nøvik
@havarnov
@jonskeet_twitter thanks. (should've been FromDays(-1))
Stephen A. Imhoff
@Clockwork-Muse
Of particular importance, not that midnight may not be the start of the day, since some DST in some zones takes place at midnight.
ANIL KUMAR ROUTHU
@TKLANIL_twitter
hi

string tz = TZConvert.WindowsToIana("Eastern Standard Time");
// result: "America/New_York"

How can we get this in javascript

Jon Skeet
@jonskeet_twitter
That really isn't a question about Noda Time - partly because Noda Time is only for .NET, and partly because the code you're quoting is using TZConvert, not Noda Time. It would be best to do research and then ask on Stack Overflow
Vladimir Chirikov
@vchirikov
hi, @jonskeet_twitter , what about BclDateTimeZoneSource in nestandard \ netcore ? When you plan 3.0 ?
Jon Skeet
@jskeet
@vchirikov: Yes, BclDateTimeZoneSource will be available cross-platform in 3.0, but 3.0 won't come until C# 8 is out. So if we're lucky, 3.0 will be late 2019. There are other things I need to look at carefully though, like whether I can support parsing ReadOnlySpan<char>.
Vladimir Chirikov
@vchirikov
@jskeet thanks for answer.
Yoav Barel
@barelyoav
I can't find these time zones "Line Islands Time","West Greenland Standard Time","Central Standard Time" anyone has the equivalent string that I should use ?
Jon Skeet
@jonskeet_twitter
@barelyoav: It's not really clear what you mean, I'm afraid. Please ask on Stack Overflow or in GitHub - both of those are much better for that sort of question (with a complete code example) than Gitter.
Yoav Barel
@barelyoav
Thanks @jonskeet_twitter , I'm trying to do: var zone = DateTimeZoneProviders.Tzdb.GetZoneOrNull("West Greenland Standard Time") for example and it is no exists in the timezone id's. I have issue only with 3 timezone: "Line Islands Time","West Greenland Standard Time","Central Standard Time"
Jon Skeet
@jonskeet_twitter
As I said before, it would be much better to ask this on Stack Overflow or GitHub.
techsico
@techsico
If I am building a python project can I use nodatime?
Jon Skeet
@jonskeet_twitter
@techsico: Not unless you're using IronPython or something else that can talk directly to .NET. You'd be better off looking at the Python date/time APIs.
Douglas Stridsberg
@Doggie52
Wrote my first piece of code with NodaTime earlier this week. Took hours but feel like I got the hang of the basics. It's a module to be plugged into a larger, time-zone unaware project - they have NT1.3.0 dependency but don't make use of it nearly enough. Feels great to finally be time-zone aware. Instant makes so much sense, really happy I found NT!
Jon Skeet
@jonskeet_twitter
@Doggie52: Glad to hear :) I'd strongly encourage moving to 2.4.x if at all possible... aside from anything else, I'm not updating the 1.x series with new time zone data any more. (You can fetch it from the web site, of course - that will still work with 1.3.0.)
Douglas Stridsberg
@Doggie52
I wish I could move to 2.4.x - the developers of the larger project do not yet share my views on the importance of being specific about time-zones
Douglas Stridsberg
@Doggie52
Part of convincing them to switch would be if there was a way to check a changelog between tzdb 2014e (1.3.0) and tzdb 2019a (for example) - do you know of any such info?
Jon Skeet
@jonskeet_twitter
Well you could diff http://nodatime.org/tzvalidate/generate?version=2019a and https://nodatime.org/tzvalidate/generate?version=2014e. But as I say, there's nothing to stop you using a recent NZD file with 1.3.0. I'd look at the other advantages of 2.x, such as nanosecond (rather than tick) precision, significant optimizations, clearer range handling, and more types. See https://nodatime.org/versions for all the changes since 1.3.0.
Douglas Stridsberg
@Doggie52
Thanks for that! Hoping I can convince them
Stephen A. Imhoff
@Clockwork-Muse

Some extra musings about TZDB-related things: Generally, you're going to want to control those updates just like any other dependency. The kicker is that:

1) Updates happen way more often (a stable NodaTime base package theoretically never updates)
2) You usually want to update the database more quickly than code
3) Depending on what other systems your code interacts with, you will also need to make sure your OS or RDBMS is updated to the same version of the TZDB. Serialized data using a zoned date-time (usually, future calendar appointments) needs to be updated appropriately.

JerzyR
@JerzyR
Trying to wrap my head around NodaTime and must say is very hard to understand and is not easy to use. I'm in Chicago and still have no idea how to get current GMT time In Australia for example.
Stephen A. Imhoff
@Clockwork-Muse

I'm in Chicago and still have no idea how to get current GMT time In Australia for example.

Well, the first thing would be that there's no such thing as "GMT time in Australia".
You can get an offset from GMT/UTC at a specific instant (or some "local" times). Which is best accomplished by getting the time zone you want first, anyways:

// Olson TZDB zones: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
DateTimeZone zone = DateTimeZoneProviders.Tzdb["Australia/Sydney"];
Offset offset = zone.GetUtcOffset(someInjectedClock.GetCurrentInstant());

.... the fact that you might be in Chicago is irrelevant.

Jon Skeet
@jonskeet_twitter
And for the someInjectedClock part, for the production dependency, you'd normally use SystemClock.Instance. Noda Time treats both time zone provision and "what's the current instant?" as services that should be injected to make testing much easier. There's a separate NodaTime.Testing package that contains a FakeClock and a (less commonly used) FakeDateTimeZoneSource so that you can inject both IClock and IDateTimeZoneProvider - then your unit tests can be completely deterministic, regardless of system time or any changes to DateTimeZoneProviders.Tzdb over the course of different Noda Time releases.
Douglas Stridsberg
@Doggie52
I'm at a loss - I believe my AtLeniently produced an unexpected result on Friday. I am not familiar with the kind of edge cases that AtLeniently makes assumptions about, would anyone have the time to look over a MWE? https://dotnetfiddle.net/0jFTax
I don't see any reason why 19 Apr would have caused any edge cases to crop up between America/New_York and Europe/London, even on tzdb2014e
Jon Skeet
@jonskeet_twitter
I'm afraid I'm finding it hard to follow your example.
The output of that is 10am London.
Which is what you said it should be in the comments.
I suggest you ask a question on Stack Overflow with clearer requirements - it'll be easier to reply there than to switch between Gitter and dotnetfiddle
Douglas Stridsberg
@Doggie52
Makes sense, and this is why I've been at a loss, I don't think this code could produce anything than 10am London, and I'm fairly sure I've boiled it down to a MWE properly. I'm increasing verbosity of my logs for the next 2 weeks and hoping I can catch it
Stephen A. Imhoff
@Clockwork-Muse
@Doggie52 - I'm suspicious of the intent in that code, though. It's implying that you're deriving the date to be closed off of the "current" date of some specific location. If close is run too late (or early, for locations east of London), that's going to change the date that gets reported (so you might close the same day twice). Business dates are only kinda related to actual calendar dates - I would normally prefer to use an explicitly chosen date for open/close (you can derive the date for user confirmation, though).
Stephen A. Imhoff
@Clockwork-Muse
It also makes me suspicious of the use of 10:00AM. Either you have an arbitrary "business date" that you explicitly open/close and bucket sales into, and thus "bucket start/end time" is irrelevant, or you're bucketing based on the absolute Instant(even if the buckets are based off of home office local time), and the time in any individual location is irrelevant.
Douglas Stridsberg
@Doggie52
Hey @Clockwork-Muse - FYI this is part of a trading algorithm where a decision needs to be made at a specific time of day, every day. This decision time of day is 10AM Ldn time and is explicit. My input is a current datetime from the system that I know the timezone of. The reason I'm using the date part of the input to get the decision time is to avoid DST ambiguities.
I understand the MWE prompts a lot of questions but I did my best to remove things that didn't factor in.
I've done some further digging and I believe the error lies elsewhere and in how I assumed my input to be a 0-tick "whole" hour whereas in reality it was often a few ticks after the hour.
Shimmy
@weitzhandler
Hi, I'm working with genealogical data and I need to be able to store a dynamic date portion, that can either be a full DateTime, Date, AnnualDate etc, all stored with EF Core.
1) Is there a generalized entity that can hold this piece of data?
2) Is there a way to store such a column with EF Core and sort rows by it?
Thank you!
Stephen A. Imhoff
@Clockwork-Muse
1) No. In a functional language you'd want what's known as a discriminated union, so you probably want to mimic that. Keep in mind that the moment somebody is born is technically an Instant, although for historical/legal reasons it's stated as some sort of ZonedDateTime (with resolution in minutes).
2) Not by default. For one thing, what meaningful sorting are you planning on doing between LocalDateTime values and AnnualDate values? LocalDateTime naturally sorts by year first. From the database side, your best bet is likely a set of nullable columns (setting less precise ones if a more precise one is specified), plus a set of separated, derived columns to perform searching/sorting on.
Shimmy
@weitzhandler
Hey and thanks for your detailed reply!
Let me narrow it down and say I want to have month/day + optional year, then be able to search whos birth-day or memorial-day happens today, so year is irrelevant to my query, but I need to be able to store and retrieve it. Are two separate columns the only solution?
Stephen A. Imhoff
@Clockwork-Muse
If you have an "optional" piece of data, in SQL-land that's a nullable column. You can abstract it by creating a custom type (which is a feature underutilized in most deployed applications) that does things like auto-convert from a date-time. Doing separate columns would also help with querying independently from year (that is, have another index on that particular column/pair).
Or, if you can guarantee that you always have a full date (birthdays always fall into this category, and for memorial dates you could use the first occurrence), you can construct all possible "first" dates with the use of a number/calendar table.
John Knoop
@johnknoop
Hi! Anyone here who by any chance remember that original video from a talk that the creator of Nodatime gave, about how the BCL datetime construct is essentially broken and introducing Nodatime? I wanna show it to a coworker, and I want to be sure I find the same video I once saw because it was very good.
Jon Skeet
@jonskeet_twitter
In terms of critiquing the BCL construction, this blog post is probably the best option: https://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html
If you mean the "Humanity: Epic Fail" talk, I don't think the video of that exists any more, but I have a blog post about it: https://codeblog.jonskeet.uk/2009/11/02/omg-ponies-aka-humanity-epic-fail/ (With currently broken pictures - I need to fix that...)
John Knoop
@johnknoop
Thanks
Hadi Eskandari
@HEskandari
Hello...Who's the best person to contact about the website on nodatime.org (specifically dotnet try stuff?)
Jon Skeet
@jonskeet_twitter
@HEskandari: Depending on the reason for contact, either email me directly (skeet@pobox.com), email the Google group, or file an issue in GitHub.
Hadi Eskandari
@HEskandari
@jonskeet_twitter thanks, I'll send you an email momentarily
Artur Malendowicz
@artur-malendowicz-gain

hello. quick question: wanted to use NodaTime to detect current IANA on iOS (xamarin) - I am based in Poland, but for me using:
DateTimeZoneProviders.Tzdb.GetSystemDefault();

always returns Europe/Zurich

Jon Skeet
@jonskeet_twitter
I suspect that's because there are no differences between Switzerland and Poland "around now" (IIRC, we detect based on offsets for two years ago to two years in the future).
(I assume TimeZoneInfo.Local.Id returns "Local" or something similarly useless? I think we use the ID or name if possible.)