43

Try running this in iOS6 (haven't tested pre iOS6):

NSDateFormatter *julianDayDateFormatter = nil;
julianDayDateFormatter = [[NSDateFormatter alloc] init];
[julianDayDateFormatter setDateFormat:@"g"];

for (NSString *timeZone in [NSTimeZone knownTimeZoneNames]) {
    julianDayDateFormatter.timeZone = [NSTimeZone timeZoneWithName: timeZone];
    NSDate *date = [julianDayDateFormatter dateFromString:[NSString stringWithFormat:@"%d", 2475213]];
    if (date == nil)
        NSLog(@"timeZone = %@", timeZone);
}

and you get the following output:

America/Bahia
America/Campo_Grande
America/Cuiaba
America/Sao_Paulo

Can anyone explain why these four time zones behave like this with NSDateFormatter set to julian day numbers? All other time zones makes NSDateFormatter return actual NSDates.

vcsjones
  • 138,677
  • 31
  • 291
  • 286
lpa
  • 710
  • 6
  • 14
  • 3
    This is a solid question, but the obvious Jon Skeet effect here is absolutely obnoxious. – jscs Oct 16 '12 at 21:21
  • 6
    @JoshCaswell: It's tricky. I'm always nervous about tweeting this sort of thing. It definitely distorts the votes - but I want to draw people's attention to something I think they'll find amusing. At least the votes for my answer are irrelevant in terms of rep... – Jon Skeet Oct 16 '12 at 22:12

2 Answers2

63

I have a suspicion. Only a suspicion, but a pretty strong one.

That value represents October 19th 2064. The Brazilian time zones observe daylight saving time starting at local midnight - that's when their clocks go forward, so midnight itself doesn't exist. October 19th is one of those transitions.

Here's some sample code using Noda Time, my .NET date/time API. It checks whether the start of the day in every time zone it knows about is actually midnight:

using System;
using NodaTime;

class Test
{
    static void Main()
    {
        var localDate = new LocalDate(2064, 10, 19);
        var provider = DateTimeZoneProviders.Tzdb;
        foreach (var id in provider.Ids)
        {
            var zone = provider[id];
            var startOfDay = zone.AtStartOfDay(localDate).LocalDateTime.TimeOfDay;
            if (startOfDay != LocalTime.Midnight)
            {
                Console.WriteLine(id);
            }
        }
    }
}

That produces a very similar list:

America/Bahia
America/Campo_Grande
America/Cuiaba
America/Sao_Paulo
Brazil/East

I suspect Brazil/East may be an alias for America/Sao_Paolo, which is why it's not on your list.

Anyway, to get back to your Julian day issue - I suspect the formatter always wants to return an NSDate * which is at the local midnight. That doesn't exist for October 19th 2064 in those time zones... hence it returns nil. Personally I'd suggest it should return the 1am value instead, but hey...

Dave DeLong
  • 242,470
  • 58
  • 448
  • 498
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Thanks. You brought me onto the right track. This definitely has to do with transitions to day light saving. For the record: iOS5 does not behave this way, it always returns an NSDate. I filled a bug with Apple. – lpa Oct 17 '12 at 08:44
  • 1
    @lpa: Out of interest, what value does it return for those time zones? If it returns a value with a local time of midnight, that's a bug in a different way? – Jon Skeet Oct 17 '12 at 08:49
  • "what value does it return for those time zones?" in iOS5? – lpa Oct 17 '12 at 09:03
  • @lpa: Yes, exactly. Local midnight doesn't exist on those dates - it would make sense to return 1am, as that's the start of the local day. – Jon Skeet Oct 17 '12 at 09:56
  • sorry for the late reply. iOS5.0 returns 1am except for Brazil which returns 12am. In iOS5.1 it returns 1am for all time zones. – lpa Oct 29 '12 at 10:07
  • *"I'd suggest it should return the 1am value instead"* – You can tell it to do so: http://stackoverflow.com/a/40320768/1187415. – Martin R Oct 29 '16 at 18:36
16

Credits to Jon Skeet for putting me on the right track. However, I just want to clarify his answer in an iOS context.

When you ask NSDateFormatter to convert a julian day number into an NSDate, you can only specify whole numbers (usually you can specify a decimal part for the hours/minutes/secs of the day) in the string to be parsed. Because Apple demarcates julian days at midnight (as opposed to noon in astronomy, read more here: http://www.unicode.org/reports/tr35/#Date_Field_Symbol_Table) and some midnights simply doesn't exists (thanks for pointing that out @JonSkeet) NSDateFormatter identifies that that particular point in time doesn't exist in that time zone and returns nil.

For the record, iOS5 does not behave like this and I agree with Jon Skeet, that NSDateFormatter should return an NSDate adjusted for DST instead of nil, as that particular julian day in fact exists! I filed a bug with Apple.

lpa
  • 710
  • 6
  • 14