jama5262 / jiffy

Jiffy is a Flutter (Android, IOS and Web) date time package for parsing, manipulating, querying and formatting dates

Jama Mohamed—@jama5262

Hi there 👋

I'm passionate about building software that improves the lives of those around me. I love Open-Source and I currently learn by building things.

Get in touch 💬

Email - [email protected]

LinkedIn - https://www.linkedin.com/in/jama-mohamed/

Twitter - https://twitter.com/timedjama5262

jiffy's Issues

Locale sv - Week should start on a Monday

Describe the bug
When having 'sv' as locale (which is great, thanks!), then you get a Sunday as start of the week, that's not correct. In Sweden we use Monday as start of the week since we follow the ISO-8601 standard as most of Europe does. This bug is in the 4.1.0 version, but I guess it has been there since the adding of the Swedish Locale 3.0.1.

in the file jiffy/lib/src/locale/availableLocales.dart in line 67 it says: 'sv': SvLocale(StartOfWeek.SUNDAY),
...but it should be: 'sv': SvLocale(StartOfWeek.MONDAY),

I would be very happy if you can fix it.

/ SuperKrallan

Jiffy in Flutter Web problem in iOSX

Jiffy works with Flutter Web in Android and desktop browsers.
I cannot use it in iOS and OSX browsers. Getting this error.

This is how i use the code
Jiffy('2020-06-19T15:37:22', 'yyyy-MM-ddTHH:mm:ss').format('MMM d, yyyy')

I pinpointed this problem because i commented out this line of code and the web app works fine.
thoughts?

for now i used a different library and it worked ok in flutter web iOSX browsers.

Output of formatted date is Wrong [yyyy-MM-dd HH:MM:SS]

Describe the bug
Output of formatted date is Wrong
To Reproduce
Steps to reproduce the behavior:

 final dt = '2022-02-07 05:00:11';
 final datm = Jiffy(dt,'yyyy-MM-dd HH:MM:ss');
 
 print ("DATE_CALC ${datm.day} - ${datm.month} - ${datm.year} ${datm.hour} : ${datm.minute} : ${datm.second}   ");

Output :
DATE_CALC 3 - 12 - 2021 5 : 0 : 11


Expected behavior
DATE_CALC 7 - 2 - 2022 5 : 0 : 11

Screenshots
If applicable, add screenshots to help explain your problem.

Jiffy Latest version

Query methods mutate the underlying date instance

Describe the bug
Any queries appear to mutate the original underlying date instance. This is a pretty major bug as performing any query therefore changes the datetime unexpectedly. Have tested it with isSame, but it looks like any query calling startOf endOf with less than ms granularity will cause the original date to lose that granularity.

To Reproduce
Steps to reproduce the behavior:

var date = Jiffy(); // date is 04/07/20 23:30
var is sameDay = date.isSame(Jiffy(), Units.DAY);
// date is now 04/07/20 23:59:59, due to calling startOf which directly changes the underlying
`_datetime` object by resetting it to `DAY` granularity to use it for comparison, instead of creating a new comparator for this purpose.

Expected behavior
Querying my dates don't change them :)

Where to put async locale set

Hi there,
where do i have to put
await Jiffy.locale('de');
in order that the locale is set app wide?
When inserting in my async main method i get this error: Unsupported operation: Cannot modify unmodifiable map
This could be since i init MaterialApp (with localizationsDelegates and supportedLocales) after this call, but this is not async anymore there.

Jiffy.unix throws JiffyException for dates before 2001/9/10

When unix timestamp in milliseconds before 2001/9/10 is entered, it's String length is only 12. Therefore JiffyException 'The timestamp passed must be in seconds or milliseconds e.g. 1570963450 or 1570963450123' is thrown.

E.g. UTC Sun Sep 09 2001 00:00:00 will return 999993600000. 1970s dates will only have timestamp length 11.

I think we need parameter or different method for seconds and milliseconds as parsing based on length won't work.

Leap year miscalculation when adding months and days

addition across leap year boundary is miscalculated.

Test to reproduce:

test(
    'test Jiffy().add() with leap-year boundary addition should add and return correct date time',
        () {
      expect(
          (Jiffy('2023-1-28 12:00:00', 'yyyy-MM-dd hh:mm:ss')
            ..add(years: 1, months: 1, days: 1))
              .dateTime
              .toString(),
          '2024-02-29 00:00:00.000');
    });

will give '2024-03-01 00:00:00.000' - which is same as adding 1 year and 1 month.
sorry for not creating a branch and pull request for fix - time presses - I will if you need me to.

Support flutter 2

Not working in flutter 2

moment parseZone

Would be good to see moment.parseZone in Jiffy.
https://momentjs.com/docs/#/parsing/parse-zone/

Jiffy().day is not returning the correct ID

Describe the bug
On my current timezone, we are Thursday. When calling Jiffy().day, the returning value is 5 (should be 4).

If I am printing this:

print(DateTime.now().weekday);

I am correctly getting 4.

To Reproduce
Steps to reproduce the behavior:
Just print (Jiffy().day);

Expected behavior
According to the documentation:

Get day of week (Returns from 0 - 6 [Sunday - Saturday])

Jiffy().day should return the correct ID of the week day

Screenshots

Desktop (please complete the following information):

• OS: Mac OS
• Version 3.0.1

Smartphone (please complete the following information):

• Device: iPhone 11 Max emulator
• OS: ios 13+

How to get this Quarter date

Hi,
how do I get the quarter date?
In moment.js, I can do like this
moment().startOf('quarter')
how do I achieve this in the flutter?

Jiffy().week gives me a wrong week number on Sunday

Hello

I have seen a strange behavior with the Jiffy package in my flutter app. Here is my code

final refDate = new DateTime(2020, 10, 18); // 18 Oct 2020
int weekNumber(DateTime date) {
  int dayOfYear = int.parse(DateFormat("D").format(date));
  return ((dayOfYear - date.weekday + 10) / 7).floor();
}

print(weekNumber(refDate));
print(Jiffy(refDate).week.toString());

The output is as follow

42
43

Can anyone explain when? I see the .week function call the same formula... (link)

Thanks!

Make start of the week configurable

Hello,

it would be nice to be able to configure start of the week to override locale's default. I have an app that manipulates time and this is an important part of an app settings for me.

Thank you

Add Ukrain local to Jiffy

parsing date/time string like "202103181200AM"

Is it possible to add support parsing such strings like "202103181200AM"?

Update intl to ^0.17.0

Describe the bug
Jiffy depends on intl but into latest is now 0.17.0.

Ordinal day 1th 2nd, 20th in Jiffy

Is your feature request related to a problem? Please describe.
Could be really cool if Jiffy could support ordinal number for the day of the month like 1st, 2nd, 3rd, 4th, 20th, 21st, etc

Describe alternatives you've considered
Something like

Jiffy([2019, 1, 1]).format("do MMM yyyy"); // 1st Jan 2019
Jiffy([2019, 1, 21]).format("do MMM yyyy"); // 21st Jan 2019
Jiffy([2019, 1, 26]).format("do MMM yyyy"); // 26th Jan 2019

Also for parsing

Jiffy("Oct, 20th 2019", "MMM, do yyyy").format("do MMM yyyy"); // 1st Jan 2019
Jiffy("Oct, 20th 2019", "MMM, do yyyy").format("do MMM yyyy"); // Oct, 20

Trying to read dd from dd/MM/yyyy at position 0 when using Arabic Locale

So when i tried to use fromNow method with any locale it was okay without any problem , But when i tried with all Arabic locales i got this error

Trying to read dd from 13/03/2021 at position 0

The used Code :

checkDate(String dateString) {
   Jiffy.locale("ar_dz");
    var jiffy = Jiffy(dateString, "dd/MM/yyyy");
    return jiffy.fromNow();
}

Comparing two different instances that hold the exact same date returns false

Describe the bug

Comparing two different instances of Jiffy that hold the exact same date results in false.

To Reproduce

Example code:

# creating two instances with identical content
final date1 = Jiffy().startOf(Units.MONTH);
final date2 = Jiffy().startOf(Units.MONTH);

# making sure they are the same
print('Date 1 is: ${  date1.dateTime  }');
print('Date 2 is: ${  date2.dateTime  }');

# comparing them and printing the result
print('These are equal: ${  date1 == date2  }');

Output:

Date 1 is: 2022-02-01 00:00:00.000
Date 2 is: 2022-02-01 00:00:00.000
These are equal: false

Expected behavior

I would expect the result to be true, in the same way as date1.dateTime == date2.dateTime also result in true.

Additional context
jiffy: ^5.0.0

Cannot parse date with format yyyyMMddhhmmss

Describe the bug
Cannot parse date with format yyyyMMddhhmmss, stacktrace:

ERROR: FormatException: Trying to read MM from 20200610094430 at position 14
package:intl/src/intl/date_format_field.dart 87:5   _DateFormatField.throwFormatException
package:intl/src/intl/date_format_field.dart 337:7  _DateFormatPatternField.parseField
package:intl/src/intl/date_format_field.dart 250:5  _DateFormatPatternField.parse
package:intl/src/intl/date_format.dart 374:13       DateFormat._parse
package:intl/src/intl/date_format.dart 303:7        DateFormat.parse
package:jiffy/src/jiffy.dart 74:14                  Jiffy._parse
package:jiffy/src/jiffy.dart 17:17                  new Jiffy
test/widget_test.dart 192:22                        main.<fn>

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Support for a fromNow taking only dates into account

Either by passing an argument to fromNow() or making a fromToday() function.

This is needed for me as the user goes through his stuff day-by-day.

Jiffy --- .fromNow()

i found that jiffy couldn't return 2 days ago
my code is Jiffy('2020-06-08').fromNow().toString(); // today -> 2020-06-10 (year-month-date)
this will return 3 days ago instead of 2 days ago..
but for another case it works well
thx

Jiffy difference

Hey jama, i just want to ask one question about the difference method. In the documentation u said that when we look for difference from this

Jiffy({ "year": 2007, "month": 1, "day": 28 }).diff([2017, 1, 29], Units.DAY); // 1

It return 1 day

My question is shouldn't it return 3651 days instead? because its 10 years and 1 day apart

Jiffy().week gives the wrong week

Jiffy().week is giving me the wrong week. Im trying to get the week number of 2020/09/06 and it gives me week 37. But it should be 36. (Monday-Sunday kind of week)

Support Duration instead string

Before:

var jiffy = Jiffy()
    .add(1, "day")
    .add(3, "hours")
    .subtract(30, "minutes")
    .add(1, "month")
    .subtract(30, "years");

After:

// Jiffy.add({Duration duration, int months, int years})
  
var jiffy = Jiffy()
    .add(duration: Duration(days: 1))
    .add(duration: Duration(hours: 3))
    .subtract(duration: Duration(minutes: 30))
    .add(months: 1)
    .subtract(years: 30);

[QUESTION] Do Getters and Setters exist for day, hour, minute etc.?

Do Getters and Setters exist for day, hour, minute etc.?

Example scenario in which this would be useful:

Say I get a TimeOfDay object inside Flutter because a user used a TimePicker.
Assume that I'd like to convert that to a Jiffy variable. To do that I'd have to somehow pass the hour and minute values I've got from TimeOfDay to the Jiffy() constructor or I'd have to overwrite the hour and minute properties of my Jiffy object.

So my question is basically whether I can directly set properties or not.

i.e.

TimeOfDay tod         = TimeOfDay.now();
Jiffy     jiff        = Jiffy();
          jiff.hour   = tod.hour;
          jiff.minute = tod.minute;

Locale de_DE not supported by fromNow()

Describe the bug
The result of Jiffy().fromNow(...) is returning the default english texts if the locale is set to 'de_DE'.

To Reproduce

final locale = await findSystemLocale(); //returns 'de_DE'
await Jiffy.locale(locale);

final result = Jiffy().fromNow()

Expected behavior
result should display the relative time in german.

Additional context
I guess this occurs as relative time only checks for 'de`, 'deat' and 'dech', not 'dede'.

jiffy vs intl

What is the advantage of using jiffy over the intl package? Thanks.

Flutter Jiffy parses local time in UTC

Is your feature request related to a problem? Please describe.
Using Flutter and sqflite to save data to the local device in the following table

CREATE TABLE records('
          'id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, '
          'phone_number TEXT, '
          'country_code TEXT, '
          'message TEXT, '
          'created DATETIME DEFAULT CURRENT_TIMESTAMP)

The datetime inserted in the created field is without timezone information

2022-01-17 19:48:34

Now using [Jiffy][1] to parse the time and display the time since the date-time, e.g., 1 minute ago.

Text(Jiffy(data.created).fromNow())

I'm in a different timezone with offset +05:30, so instead of displaying 1 minute ago, it displays 6 hours ago.

How to parse the date-time in the local timezone instead of UTC with Jiffy?

Describe the solution you'd like
Tell Jiffy, the timezone to use for the passed date-time. Or treat as local time by default.

Describe alternatives you've considered

Additional context

Incorrect behaviour of add method when traversing a date in which daylight saving time transition occurs

Hi,
I have recently stumbled over this problem. My current timezone is 'Europe/Rome', where DST switches off the last Sunday of October. If I execute

Jiffy('2020-10-19 00:00:00').add(weeks: 1)

due to the DST transition, the result is not 2020-10-26 00:00:00, as I would expect, but 2020-10-25 23:00:00. This breaks all the rest of my computation.

I think the behavior of Jiffy is incorrect. Adding a week should return 2020-10-26 00:00:00, independently from the actual number of hours of difference. As a comparison, the momentjs library with

moment('2020-10-19 00:00:00').add(1, 'weeks')

correctly returns Moment<2020-10-26T00:00:00+01:00>.

This is not the only instance of this problem. For example,

Jiffy('2020-10-25 00:00:00').add(days: 1)

returns again 2020-10-25 23:00:00 instead of ``2020-10-26 00:00:00```.

startOf always returns non utc date even if date was utc

Describe the bug
Jiffy(Jiffy().utc()).dateTime.isUtc returns true
Jiffy(Jiffy().utc()).startOf(Units.MONTH).isUtc returns false

Expected behavior
If date was in UTC, startOf should return UTC DateTime object

Smartphone (please complete the following information):

• Device: iPhone12
• OS: iOS14

startOf("w") and endOf("") don't support locales + week getter bug

Describe the bug
The current implementation of startOf() doesn't support locales customization. That makes that startOf("w") to always return sunday at midnight as the first day of the week without possibility to return monday depending of the locale.

await Jiffy.locale("fr");

var today = Jiffy();
today.yMMMEdj; // "11 nov. 2019 08:29" --> Monday

var startOfWeek = Jiffy().startOf("w");
startOfWeek.yMMMEdj; // "10 nov. 2019 00:00" --> Sunday

var endOfWeek = Jiffy().endOf("w");
endOfWeek.yMMMEdj; // "16 nov. 2019 23:59" --> Saturday

Also I think there is something wrong with the .week getter

today.week // 46
startOfWeek.week // 45
endOfWeek.week // 45

Expected behavior

• startOf("w") should return monday for an European timezone
• today's week, startOfWeek and endOfWeek should be in the same week

Additional context
I put the two issues into the same because I think they have the same root cause -> locales support.

As discussed earlier, startOf() and endOf() don't support locales customization and they are coded for the US/Canada...

And the week getter makes use of DateTime.weekday that is coded according to the international standard ISO 8601, where Monday is the first day of the week so it returns the week before when asked for startOf("w")

.add() and .substract() methods are returning void

Describe the bug
.add() and .substract() methods are returning void. Checked in version 5.0.0 and 4.0.0

Expected behavior
Expect these methods to return a DateTime value

Day of week index calculated wrong

Describe the bug
A clear and concise description of what the bug is.
On documentation is described that Jiffy().day will return an index from 0-6 but it returns an index 1-7;

Days in Month

Is your feature request related to a problem? Please describe.
Jiffy to be able to return days in a month

Describe the solution you'd like
Example, days in month for Jan would return 31 and as for Apr 30

Describe alternatives you've considered

Jiffy([2016, 1]).daysInMonth; // 31
Jiffy([2016, 2]).daysInMonth; // 28
Jiffy([2017, 2]).daysInMonth; // 29

parsing short year format (ex: d.m.yy)

Describe the bug
Parsing two-digit year 19 with results in 0019 and not 2019

DateTime dateTimeConverter(String date) {
  return Jiffy(date, 'MM/dd/yy, HH:mm a').dateTime;
}

Testing

  test('date', () {
    expect(dateTimeConverter('3/23/19, 3:03 PM'), DateTime(2019, 3, 23, 15, 3));
  });

testing fail
Expected: DateTime:<2019-03-23 15:03:00.000>
Actual: DateTime:<0019-03-23 15:03:00.000>

Can't use get methods after converting unixtime value to Jiffy object.

Describe the bug
After converting unixtime to Jiffy object by Jiffy.unix() i can't use the .day to get the day from the converted time.

void convertTime(int unixTime) { var dateDay = Jiffy.unix(unixTime); print(dateDay); }

Expected behaviour
I expect to be able to use the get properties on the converted JIffy object from the unix time value(e.g : 1617345000) .

Week days and week count

I'm not sure why is this implemented that way, for me this is incorrect, everybody knows a week starts from Monday, but instead your week day is 0-6 Sunday to Saturday?
Next big thing with the same logic, one record is on Saturday, next one is on Sunday and your logic makes them in different weeks. This is wrong. Maybe consider having a setting to set which is the first day of the week so that the calculations are correct. This is a show stopper for me. I'm trying to group records by week to show a bar chart, but I'm getting wrong results.

Wrong calculation for subtracting days for April 1st of 2021 for en_US.

Describe the bug
The straightforward calculation yields wrong data.
The same case is for Flutter's DateTime class.
The culprit is subract days method.

To Reproduce
Steps to reproduce the behavior:

1. Run the app on en_US locale.
2. Make date with Jiffy: Jiffy([2021, 4, 1])
3. subtract 4 days: Jiffy([2021, 4, 1])..subtract(4)
4. Observe March 27, not March 28.

Expected behavior
Subtracting should yield correct date.

Additional context
Looks related with Flutter framework.

Ideas on Jiffy

1. There should be operator==() aliasing .isSame().
2. Same concept applies for .isSameOrBefore(), .isSameOrAfter(), .isBefore(), .isAfter().
3. This will provide a native Dart way for sorting like in a List.
4. .isJiffy() and .isDateTime() can be done by XXX is Jiffy or is DateTime. These two functions can be eliminated.
5. The locale should be default to device locale and failover to en if not supported instead of requiring to set locale to use on every single time.

Jiffy.from(x)

i am building an app using Jiffy package. and i am getting this error

this is a snippet of my code, my variable initialization and failing code snippet

i am trying to get the time difference of the forecast day from today as per the documentation

i cant seem to get it working.

Compile error

Because every version of flutter_localizations from sdk depends on intl 0.17.0-nullsafety.2 and jiffy 3.0.1 depends on intl ^0.16.0, flutter_localizations from sdk is incompatible with jiffy 3.0.1.
And because no versions of jiffy match >3.0.1 <4.0.0, flutter_localizations from sdk is incompatible with jiffy ^3.0.1.
So, because fanroom depends on both jiffy ^3.0.1 and flutter_localizations any from sdk, version solving failed.

Undefined name 'Units'.

Unable to use 'Units'

String d = Jiffy(date).isAfter(toUtc, Units.YEAR ) ? 'Date' : Jiffy(date).from(toUtc);

Is there a way to get a difference between dates without specifying units?

Is your feature request related to a problem? Please describe.
Jiffy({
"year": 2007,
"month": 1,
"day": 28
}).diff([2017, 1, 29], Units.DAY); // 1

I would like to have a difference method that would choose the most logical units without me having to specify it.

Describe the solution you'd like
For example:

• Difference is 0.3 minutes => would display 18 seconds
• Difference is 61 minutes => would display 1 hour and 1 minute
• Difference is 26h42mins => would display 1 day, 2 hours and 42 minutes

Describe alternatives you've considered
The only alternative right now that I can see is the relative time methods, but I don't want the "ago" suffix.

This would be very useful, in my opinion, for when you want to display the time something took to do, when you have the initial timestamp and the ending timestamp and want to see the difference between the two.

Thank you.

A getter or method to convert Jiffy to DateTime — eg. .toDateTime()

It would be great if we could easily convert from Jiffy to DateTime or vice versa.
Thanks 😊

Can't use jiffy and angular dart because of intl

isn't it possible to use intl 0.15 instead of 0.16?
so it would be possible to use it along angular dart.

Jiffy Difference

I am unable to receive back a double from adding 'true' as a third parameter when using Units.HOUR:

var jiffy1 = Jiffy("10:00 AM", "h:mm a");
var jiffy2 = Jiffy("10:30 PM", "h:mm a");

jiffy1.diff(jiffy2, Units.HOUR); // -12
jiffy1.diff(jiffy2, Units.HOUR, true); // -12, from my understanding should be -12.5

My results always truncate to a whole number.

Anyone else get this when trying?

Migration information seems to be missing.

The change away from implicit casting to DateTimes with 4.0.0 seems like a good one. However, this is an important, breaking change and I don't see any guidance. There's got to be a lot of code out there that broke because it expected the output of a method call on a Jiffy object to return a DateTime. An example:

This worked before

DateTime time = startTime = Jiffy(Jiffy(currentTime).add(weeks: timeOffset * 7)).startOf(Units.WEEK);

And this works now

Jiffy jiffyTime = Jiffy(Jiffy(currentTime)..add(weeks: timeOffset * 7))..startOf(Units.WEEK);
DateTime time = jiffyTime.dateTime;

But is that the right way to do it? Is there a more elegant way that doesn't introduce a new variable? How would one know? Tagging on .local() or .utc() or ..local() or ..utc() didn't work.

Thank you for this excellent package that makes working with DateTimes in Dart sane, and my bad if this sort of migration is documented somewhere.

Type-safe Jiffy constructor

I would like to see Jiffy as a type-safe solution.

Use case:
You have DateTime everywhere, but you decide to write a custom Date class (because you only need dates in many places), you replace DateTime with Date. But Jiffy constructor accepts dynamic, and it doesn't throw in compile time.

I propose:
Leave Jiffy() empty constructor public. Make Jiffy([var input]) private, and create factory Jiffy.fromDateTime(DateTime date) => Jiffy._(date); for each of types.

Jiffy.dateTime(), Jiffy.map() are also good.

What do you think? I could PR.

Jiffy methods should always return a Jiffy type

Is your feature request related to a problem? Please describe.
It's difficult to reason when a jiffy returns a different type, and it makes chaining calculations verbose and confusing.

final beginning = Jiffy(date).startOf(Units.DAY);
final end = Jiffy(date)
  ..startOf(Units.DAY)
  ..add(days: 1);

print(beginning); // returns DateTime
print(end); // returns Jiffy

Describe the solution you'd like
Jiffy methods should always return a Jiffy type. That way the above calculation would become

final beginning = Jiffy(date).startOf(Units.DAY);
final end = beginning.add(days: 1);

print(beginning.dateTime);
print(end.dateTime);

Describe alternatives you've considered
Rather than using moment.js in my js projects, I've been using Luxon (also maintained by moment) which I've found is infinitely better. Personally if i was to make a date package in dart I would base it off Luxon instead.