Just wanted to let the Noda Time Community know that I ported your library to another language, here. If anything looks amiss (like, maybe the licensing is incorrect? -- I don't think it is, but maybe), let me know. -- I feel like, I should have informed you all of this sooner (a common courtesy?), but I'm not quite sure when a project crosses the line from something you might not get far on, to something that you're pretty confident you're going to keep at.
@nawfalhasan I did think about that, but doda is a real place, searching for
doda time gets you Doda's Time
is the following correct way to get start of day and start of next day in a timezone?
var endLocalDate = now.InZone(tz).Date;
var startLocalDate = LocalDate.Add(endLocalDate, Period.FromDays(1));
var end = endLocalDate.AtMidnight().InUtc();
var start = startLocalDate.AtMidnight().InUtc();
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...
string tz = TZConvert.WindowsToIana("Eastern Standard Time");
// result: "America/New_York"
How can we get this in javascript
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"
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!
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.
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.
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.
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.
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
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
@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).
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.
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.
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.
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
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!
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!
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
2) Not by default. For one thing, what meaningful sorting are you planning on doing between
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.
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?
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?
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.
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.
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...)